Cuál es la diferencia entre null= Verdadero y en blanco = Verdadero en Django?

Nuestro team de redactores ha pasado mucho tiempo investigando la respuesta a tu búsqueda, te regalamos la respuesta por esto esperamos servirte de gran ayuda.

Solución:

null=True conjuntos NULL (versus NOT NULL) en la columna de su base de datos. Valores en blanco para tipos de campo de Django como DateTimeField o ForeignKey se almacenará como NULL en la base de datos.

blank determina si el campo será obligatorio en los formularios. Esto incluye el administrador y sus formularios personalizados. Si blank=True entonces 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, por lo general, si va a permitir que un campo esté en blanco en su formulario, también necesitará que su base de datos permita NULL valores para ese campo. La excepción es CharFieldarena TextFields, que en Django son Nunca guardado como NULL. Los valores en blanco se almacenan en la base de datos como un string ('').

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 sentido lógico de usar (aunque podría haber un caso de uso para null=True, blank=False si desea que un campo siempre sea obligatorio en los formularios, es opcional cuando se trata de un objeto a través de algo 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 los 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 en el que eso podría ser necesario, aún debe incluir null=True.

Así es como se mapea el ORM blank Y 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 están :

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 están :

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
)

Es crucial comprender que las opciones en una definición de campo de modelo de Django sirven (al menos) para 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 se pueden anular proporcionando un formulario personalizado). Algunas opciones afectan la base de datos, algunas opciones afectan los formularios y algunas afectan a ambos.

Cuando se trata de null y blank, otras respuestas ya han dejado claro que el primero afecta la definición de la tabla de la base de datos y el segundo afecta la validación del modelo. Creo que la distinción se puede hacer 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 todas las circunstancias.

• 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 string-campos basados ​​en opcionales.)

• null=False, blank=True: Esto significa que el formulario no requiere un valor, pero la base de datos sí. Hay varios casos de uso para esto:

  • El uso más común es opcional. string-campos basados ​​en. Como se indica en la documentación, el idioma de Django es usar el vacío string para indicar un valor faltante. Si NULL También se le permitió terminar 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 save() método, digamos). No desea que el usuario proporcione el valor en un formulario (por lo tanto blank=True), pero desea que la base de datos imponga que siempre se proporciona un valor (null=False).

  • Otro uso es cuando se quiere 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 Sin embargo, seguirá afectando a 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 que se usa 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. 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 necesitan la misma validación estricta que desea exigir a un editor humano.

  • Otro caso de uso que he visto es cuando tienes un ForeignKey para el que no desea permitir la eliminación en cascada. Es decir, en uso normal, la relación siempre debería estar ahí (blank=False), pero si lo que apunta se elimina, no desea 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.

Sección de Reseñas y Valoraciones

Eres capaz de añadir valor a nuestro contenido colaborando tu veteranía en las notas.

---

---

Utiliza Nuestro Buscador