python - integerfield - nullable field django




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

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

  1. null=True solo null=True
  2. blank=True solamente
  3. 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

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.


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

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.



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.


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 .





django-models