python - example - models django unique

diferencie null=True, blank=True en django (12)

Cuando agregamos un campo de base de datos en django, generalmente escribimos models.CharField(max_length=100, null=True, blank=True) . Lo mismo se hace con ForeignKey , DecimalField , etc. ¿Cuál es la diferencia básica en tener

null=True solo null=True
blank=True solamente
null=True , en blank=True

con respecto a los diferentes CharField ( CharField , ForeignKey , ManyToManyField , DateTimeField ). ¿Cuáles son las ventajas / desventajas de usar 1/2/3?

Aquí hay un ejemplo del campo con blank= True y null=True

description = models.TextField (blank = True, null = True)

En este caso: blank = True : indica a nuestro formulario que está bien dejar el campo de descripción en blanco

null = True : le dice a nuestra base de datos que está bien registrar un valor nulo en nuestro campo db y no dar un error.

Aquí, es la principal diferencia de null=True y blank=True :

El valor predeterminado de null y en blank es Falso. Ambos valores funcionan a nivel de campo, es decir, si queremos mantener un campo null o en blank .

null=True establecerá el valor del campo en NULL , es decir, sin datos. Es básicamente para el valor de la columna de bases de datos.

date = models.DateTimeField(null=True)

blank=True determina si el campo será requerido en los formularios. Esto incluye el administrador y sus propios formularios personalizados.

title = models.CharField(blank=True) // title can be kept blank. En la base de datos ("") se almacenará. null=True blank=True Esto significa que el campo es opcional en todas las circunstancias.

epic = models.ForeignKey(null=True, blank=True) // The exception is CharFields() and TextFields(), which in Django are never saved as NULL. Blank values a

Así es como el ORM asigna campos en blank y null para Django 1.8

class Test(models.Model): charNull = models.CharField(max_length=10, null=True) charBlank = models.CharField(max_length=10, blank=True) charNullBlank = models.CharField(max_length=10, null=True, blank=True) intNull = models.IntegerField(null=True) intBlank = models.IntegerField(blank=True) intNullBlank = models.IntegerField(null=True, blank=True) dateNull = models.DateTimeField(null=True) dateBlank = models.DateTimeField(blank=True) dateNullBlank = models.DateTimeField(null=True, blank=True)

Los campos de la base de datos creados para PostgreSQL 9.4 son:

CREATE TABLE Test ( id serial NOT NULL, "charNull" character varying(10), "charBlank" character varying(10) NOT NULL, "charNullBlank" character varying(10), "intNull" integer, "intBlank" integer NOT NULL, "intNullBlank" integer, "dateNull" timestamp with time zone, "dateBlank" timestamp with time zone NOT NULL, "dateNullBlank" timestamp with time zone, CONSTRAINT Test_pkey PRIMARY KEY (id) )

Los campos de la base de datos creados para MySQL 5.6 son:

CREATE TABLE Test ( `id` INT(11) NOT NULL AUTO_INCREMENT, `charNull` VARCHAR(10) NULL DEFAULT NULL, `charBlank` VARCHAR(10) NOT NULL, `charNullBlank` VARCHAR(10) NULL DEFAULT NULL, `intNull` INT(11) NULL DEFAULT NULL, `intBlank` INT(11) NOT NULL, `intNullBlank` INT(11) NULL DEFAULT NULL, `dateNull` DATETIME NULL DEFAULT NULL, `dateBlank` DATETIME NOT NULL, `dateNullBlank` DATETIME NULL DEFAULT NULL )

Como se dijo en la referencia de Django Model Field: Link

Opciones de campo

Los siguientes argumentos están disponibles para todos los tipos de campo. Todos son opcionales.

`null`

Field.null

Si es True , Django almacenará valores vacíos como NULL en la base de datos. El valor predeterminado es False .

Evite utilizar null en campos basados en cadenas como CharField y TextField porque los valores de cadenas vacías siempre se almacenarán como cadenas vacías, no como NULL . Si un campo basado en cadena tiene null=True , eso significa que tiene dos valores posibles para "sin datos": NULL y la cadena vacía. En la mayoría de los casos, es redundante tener dos valores posibles para "sin datos"; La convención de Django es usar la cadena vacía, no NULL .

Tanto para los campos basados en cadenas como para los no basados en cadenas, también deberá establecer blank=True si desea permitir valores vacíos en los formularios, ya que el parámetro null solo afecta al almacenamiento de la base de datos (ver en blank ).

Nota
Cuando se utiliza el backend de la base de datos Oracle, el valor NULL se almacenará para denotar la cadena vacía independientemente de este atributo

`blank`

Field.blank

Si es True , se permite que el campo esté en blanco. El valor predeterminado es False .

Tenga en cuenta que esto es diferente de null . null está puramente relacionado con la base de datos, mientras que en blank está relacionado con la validación. Si un campo tiene en blank=True , la validación del formulario permitirá la entrada de un valor vacío. Si un campo tiene en blank=False , el campo será requerido.

Creo que puede interesarle Guardar el CharField vacío y que puede ser anulable como nulo en lugar de como una cadena vacía . Hay muchas discusiones sobre esto y un problema muy práctico que puede encontrar (por ejemplo, si desea agregar una URL de OpenID para cada usuario, que puede ser nula y debería ser única).

Cuando guardamos algo en el administrador de Django, se realizan dos pasos de validación, en el nivel de Django y en el nivel de la base de datos. No podemos guardar texto en un campo numérico.

La base de datos tiene el tipo de datos NULL, no es nada. Cuando Django crea columnas en la base de datos, especifica que no pueden estar vacías. Y si intenta guardar NULL obtendrá el error de la base de datos.

También en el nivel Django-Admin, todos los campos son obligatorios por defecto, no puede guardar un campo en blanco, Django le lanzará un error.

Por lo tanto, si desea guardar un campo en blanco, debe permitirlo en Django y en el nivel de Base de datos. blank = True - permitirá el campo vacío en el panel de administración null = True - permitirá guardar NULL en la columna de la base de datos.

Cuando se analizan las opciones en una definición de modelo de Django, es crucial entender que cumplen (al menos) dos propósitos: definir las tablas de la base de datos y definir el formato predeterminado y la validación de los formularios modelo. (Digo "predeterminado" porque los valores siempre se pueden anular proporcionando un formulario personalizado). Algunas opciones afectan a la base de datos, otras afectan a los formularios y otras afectan a ambos.

Cuando se trata de un null y en blank , otras respuestas ya han dejado en claro que la primera afecta a la definición de la tabla de la base de datos y la segunda a la validación del modelo. Creo que la distinción se puede hacer aún más clara al observar los casos de uso de las cuatro configuraciones posibles:

null=False , blank=False : esta es la configuración predeterminada y significa que el valor es obligatorio en todas las circunstancias.
null=True , blank=True : Esto significa que el campo es opcional en todas las circunstancias. (Sin embargo, como se indica a continuación, esta no es la forma recomendada de hacer que los campos basados en cadenas sean opcionales).
null=False , blank=True : Esto significa que el formulario no requiere un valor, pero la base de datos lo requiere. Hay varios casos de uso para esto:
- El uso más común de esta configuración es para campos opcionales basados en cadenas. Como se indica en la documentación , el idioma de Django es usar la cadena vacía para indicar un valor faltante. Si también se permitiera NULL , terminaría con dos formas diferentes de indicar un valor faltante.
- Otra situación común es que desea calcular un campo automáticamente en función del valor de otro (en su método save() , por ejemplo). No desea que el usuario proporcione el valor en un formulario (por lo tanto, en blank=True ), pero sí quiere que la base de datos haga cumplir que siempre se proporciona un valor ( null=False ).
- Otro uso de esta configuración es cuando desea indicar que ManyToManyField es opcional. Debido a que este campo se implementa como una tabla separada en lugar de una columna de base de datos, el null tiene sentido . Sin embargo, el valor de blank todavía afectará las formas, controlando si la validación tendrá éxito o no cuando no haya relaciones.
null=True , blank=False : Esto significa que el formulario requiere un valor, pero la base de datos no. Esta puede ser la configuración utilizada con menos frecuencia, pero existen algunos casos de uso para ella:
- Es perfectamente razonable exigir a sus usuarios que siempre incluyan un valor, incluso si su lógica empresarial no lo requiere realmente. Después de todo, los formularios son solo una forma de agregar y editar datos. Es posible que tenga un código que genere datos que no necesiten la misma validación estricta que desea un editor humano.
- Otro caso de uso para esto que he visto es cuando tiene una ForeignKey para la que no desea permitir la eliminación en cascada . Es decir, en el uso normal, la relación siempre debe estar ahí (en blank=False ), pero si la cosa a la que apunta sucede que se eliminará, no desea que este objeto se elimine también. En ese caso, puede usar null=True y on_delete=models.SET_NULL para implementar un tipo simple de eliminación suave .

Hay un punto donde null=True sería necesario incluso en un CharField o TextField y es cuando la base de datos tiene el indicador unique establecido para la columna.

En otras palabras, si tienes un Char / TextField único en Django, necesitarás usar esto:

models.CharField(blank=True, null=True, unique=True)

Para CharField o TextField no únicos, será mejor que omita el null=True contrario, algunos campos se establecerán como NULL mientras que otros como "", y tendrá que verificar el valor del campo para NULL cada vez.

Puede tener su respuesta, sin embargo, hasta este día es difícil juzgar si poner null = True o blank = True o ambos en un campo. Personalmente, creo que es bastante inútil y confuso proporcionar tantas opciones a los desarrolladores. Deje que los nulos o espacios en blanco lo dejen como quieran.

Sigo esta tabla:

Simplemente null=True define la base de datos debe aceptar valores NULL , por otra parte blank=True define en la validación de formulario este campo debe aceptar valores en blanco o no (Si blank=True , acepta formulario sin un valor en ese campo y blank=False [valor predeterminado ] en la validación del formulario mostrará este campo es un error requerido .

null=True/False relacionado con la base de datos

blank=True/False relacionado con la validación de formularios

null=True establece NULL (versus NOT NULL ) en la columna de su base de datos. Los valores en blanco para los tipos de campo Django, como DateTimeField o ForeignKey , se almacenarán como NULL en la base de datos.

blank=True determina si el campo será requerido en los formularios. Esto incluye el administrador y sus propios formularios personalizados. Si blank=True , el campo no será obligatorio, mientras que si es False el campo no puede estar en blanco.

La combinación de los dos es muy frecuente porque normalmente si va a permitir que un campo esté en blanco en su formulario, también necesitará que su base de datos permita valores NULL para ese campo. La excepción es CharField y TextField , que en Django nunca se guardan como NULL . Los valores en blanco se almacenan en la base de datos como una cadena vacía ( '''' ).

Algunos ejemplos:

models.DateTimeField(blank=True) # raises IntegrityError if blank models.DateTimeField(null=True) # NULL allowed, but must be filled out in a form

Obviamente, estas dos opciones no tienen un sentido lógico de usar (aunque, puede haber un caso de uso para null=True, blank=False si desea que siempre se requiera un campo en los formularios, pero es opcional cuando se trata de un objeto a través de algo como la concha.

models.CharField(blank=True) # No problem, blank is stored as '''' models.CharField(null=True) # NULL allowed, but will never be set as NULL

CHAR tipos CHAR y TEXT nunca se guardan como NULL por Django, por lo que null=True es necesario. Sin embargo, puede configurar manualmente uno de estos campos en None para forzar su configuración como NULL . Si tiene un escenario en el que podría ser necesario, aún debe incluir null=True .

null = True

Significa que no hay ninguna restricción de la base de datos para que se complete el campo, por lo que puede tener un objeto con un valor nulo para el relleno que tiene esta opción.

blank = True

Significa que no hay ninguna restricción de validación en los formularios de django. por lo tanto, cuando rellena un modelForm de modelForm para este modelo, puede dejar el campo con esta opción sin completar.