Pregunta diferenciar null = True, blank = True en django


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 ¿Cuál es la diferencia básica en tener

  1. null=True solamente
  2. blank=True solamente
  3. null=True, blank=True

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


619
2017-12-22 20:11


origen


Respuestas:


null=True conjuntos NULL (versus NOT NULL) en la columna en tu DB. Valores en blanco para tipos de campo de Django, como DateTimeField o ForeignKey será almacenado como NULL en el DB.

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

El combo de los dos es muy frecuente porque, por lo general, si va a permitir que un campo quede en blanco en su formulario, también necesitará que su base de datos permita NULL valores para ese campo. La excepción es CharFields y TextFields, que en Django son Nunca guardado como NULL. Los valores en blanco se almacenan en el DB 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, esas 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 opcional cuando se trata de un objeto a través de algo así como el shell).

models.CharField(blank=True) # No problem, blank is stored as ''

models.CharField(null=True) # NULL allowed, but will never be set as NULL

CHAR y TEXT tipos nunca se guardan como NULL por Django, entonces null=True es innecesario Sin embargo, puede configurar manualmente uno de estos campos para None forzar establecerlo como NULL. Si tiene un escenario donde podría ser necesario, aún debe incluir null=True.


740
2017-12-22 20:35



Así es como los mapas ORM blank & null campos 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
)

75
2018-02-16 14:00



Como se dijo en Django Model Field referencia: Enlazar

Opciones de campo

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


null

Field.null

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

Evitar el uso de null en campos basados ​​en cadenas tales 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 cadenas tiene null=True, eso significa que tiene dos valores posibles para "sin datos": NULLy 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.

Para campos basados ​​en cadenas y no basados ​​en cadenas, también necesitará establecer blank=True si desea permitir valores vacíos en formularios, como null parámetro solo afecta el almacenamiento de la base de datos (ver blank)

Nota

Al utilizar el back-end 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 True, el campo puede estar 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 blankestá relacionado con la validación Si un campo tiene blank=True, la validación de formulario permitirá la entrada de un valor vacío. Si un campo tiene blank=False, el campo será requerido.


17
2018-04-16 18:54



Simplemente null=True define la base de datos debe aceptar NULL valores, por otro lado blank=True define en la validación de formulario que 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 requerido error.

null=True/False relacionado con la base de datos

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


15
2017-09-11 04:26



Cuando se analizan las opciones en una definición de modelo de Django, es crucial entender que sirven (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 del modelo. (Digo "predeterminado" porque los valores siempre pueden anularse proporcionando un formulario personalizado). Algunas opciones afectan a la base de datos, algunas opciones afectan a formularios y otras afectan a ambas.

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

  • null=False, blank=False: Esta es la configuración predeterminada y significa que el valor es obligatorio en cualquier circunstancia.

  • null=True, blank=True: Esto significa que el campo es opcional en todas las circunstancias. (Como se indica a continuación, sin embargo, esto es no 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 sí lo requiere. Hay una serie de casos de uso para esto:

    • El uso más común de esta configuración es para campos opcionales basados ​​en cadenas. Como anotado en la documentación, el modismo Django es usar la cadena vacía para indicar un valor perdido. Si NULL También se le permitió terminar con dos formas diferentes de indicar un valor perdido, que sería menos que ideal.

    • Otra situación común es que desea calcular un campo automáticamente en función del valor de otro (en su save() método, por ejemplo). No desea que el usuario proporcione el valor en una forma (por lo tanto, blank=True), pero desea 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 un ManyToManyField es opcional. Debido a que este campo se implementa como una tabla separada en lugar de una columna de base de datos, null no tiene sentido. El valor de blank aún afectará a los formularios, sin embargo, el control de 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 hay algunos casos de uso para ella:

    • Es perfectamente razonable exigir a los usuarios que siempre incluyan un valor, incluso si su lógica comercial no lo requiere. Después de todo, los formularios son solo una forma de agregar y editar datos. Es posible que tenga un código que genera datos que no necesita la misma validación estricta que desea que requiera un editor humano.

    • Otro caso de uso para esto que he visto es cuando tienes un ForeignKey para lo cual no deseas permitir eliminación en cascada. Es decir, en uso normal, la relación siempre debe estar allí (blank=False), pero si sucede que se borra lo que señala, no quiere que este objeto también se elimine. En ese caso, puedes usar null=True y on_delete=models.SET_NULL para implementar un tipo simple de eliminación suave.


6
2017-12-01 09:20



Aquí hay un ejemplo del campo con blank = true y null = true     description = models.TextField (en blanco = verdadero, nulo = verdadero)

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

y

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.


1
2018-01-01 21:42



Cuando guardamos algo en el administrador de Django ocurre la validación de dos pasos, 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 el 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 la 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.


0
2018-05-11 23:58