Was ist der Unterschied zwischen null=True und blank=True in Django?

Question

Wenn wir ein Model-Feld in Django hinzufügen, schreiben wir im Allgemeinen:

models.CharField(max_length=100, null=True, blank=True)

Dasselbe wird mit ForeignKey, DecimalField usw. gemacht. Was ist der grundlegende Unterschied zwischen:

1. null=True nur
2. blank=True nur
3. null=True und blank=True

im Vergleich zu verschiedenen (CharField, ForeignKey, ManyToManyField, DateTimeField) Feldern? Was sind die Vor- und Nachteile der Verwendung von Option 1, 2 oder 3?

Answer 1

null=True legt NULL (gegenüber NOT NULL) für die Spalte in Ihrer DB fest. Leerwerte für Django-Feldtypen wie DatumZeitFeld oder Fremdschlüssel werden als NULL in der DB gespeichert.

blank bestimmt, ob das Feld in Formularen erforderlich ist. Dies gilt auch für den Admin-Bereich und Ihre benutzerdefinierten Formulare. Wenn blank=True ist, ist das Feld nicht erforderlich, während es bei False nicht leer sein darf.

Die Kombination der beiden ist so häufig, weil typischerweise, wenn Sie ein Feld in Ihrem Formular leer zulassen möchten, auch Ihrem Datenbank erlauben müssen, NULL-Werte für dieses Feld zuzulassen. Die Ausnahme bilden CharFields und TextFields, die in Django niemals als NULL gespeichert werden. Leerwerte werden in der DB als leerer String ('') gespeichert.

Ein paar Beispiele:

models.DateTimeField(blank=True) # wirft IntegrityError bei Leerwert

models.DateTimeField(null=True) # NULL erlaubt, muss aber in einem Formular ausgefüllt werden

Offensichtlich ergeben diese beiden Optionen keinen logischen Sinn (obwohl es möglicherweise einen Anwendungsfall für null=True, blank=False gibt, wenn Sie möchten, dass ein Feld immer in Formularen benötigt wird, optional, wenn Sie mit einem Objekt durch etwas wie die Shell arbeiten.)

models.CharField(blank=True) # Kein Problem, Leerwert wird als ''

models.CharField(null=True) # NULL erlaubt, wird jedoch nie als NULL festgelegt

CHAR und TEXT-Typen werden von Django nie als NULL gespeichert, daher ist null=True unnötig. Sie können jedoch manuell eines dieser Felder auf None setzen, um es explizit auf NULL zu setzen. Wenn Sie ein Szenario haben, in dem dies erforderlich sein könnte, sollten Sie dennoch null=True einschließen.

Answer 2

Dies ist, wie der ORM blank & null Felder für Django 1.8 abbildet

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)        

Die Datenbankfelder, die für PostgreSQL 9.4 erstellt wurden sind :

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)
)

Die Datenbankfelder, die für MySQL 5.6 erstellt wurden sind :

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
)

Answer 3

Es ist entscheidend zu verstehen, dass die Optionen in einer Django-Modellfelddefinition (mindestens) zwei Zwecke erfüllen: die Definition der Datenbanktabellen und die Definition des Standardformats und der Validierung von Modellformularen. (Ich sage "Standard", weil die Werte immer durch Bereitstellung eines benutzerdefinierten Formulars überschrieben werden können.) Einige Optionen beeinflussen die Datenbank, einige beeinflussen Formulare und einige beeinflussen beides.

Wenn es um null und blank geht, haben andere Antworten bereits klargestellt, dass ersteres die Definition der Datenbanktabelle betrifft und letzteres die Modellvalidierung beeinflusst. Ich denke, die Unterscheidung kann noch klarer gemacht werden, wenn man sich Anwendungsfälle für alle vier möglichen Konfigurationen ansieht:

• null=False, blank=False: Dies ist die Standardkonfiguration und bedeutet, dass der Wert unter allen Umständen erforderlich ist.

• null=True, blank=True: Dies bedeutet, dass das Feld unter allen Umständen optional ist. Wie unten erwähnt, ist dies jedoch nicht der empfohlene Weg, um stringbasierte Felder optional zu machen.

• null=False, blank=True: Dies bedeutet, dass das Formular keinen Wert erfordert, die Datenbank aber schon. Es gibt eine Reihe von Anwendungsfällen für dies:

  • Der häufigste Gebrauch ist für optionale stringbasierte Felder. Wie in der Dokumentation festgehalten, ist das Django-Idiom, das leere Zeichenfolge zu verwenden, um einen fehlenden Wert anzuzeigen. Wenn auch NULL erlaubt wäre, würden Sie zwei verschiedene Möglichkeiten haben, einen fehlenden Wert anzugeben. (Wenn das Feld auch unique ist, müssen Sie jedoch null=True verwenden, um zu verhindern, dass mehrere leere Zeichenfolgen die Eindeutigkeitsüberprüfung nicht bestehen.)

  • Ein weiterer häufiger Fall ist, wenn Sie ein Feld automatisch basierend auf dem Wert eines anderen berechnen möchten (in Ihrer save()-Methode zum Beispiel). Sie möchten nicht, dass der Benutzer den Wert in einem Formular angibt (deshalb blank=True), aber Sie möchten, dass die Datenbank durchsetzt, dass immer ein Wert angegeben wird (null=False).

  • Ein weiterer Einsatz ist, wenn Sie anzeigen möchten, dass ein ManyToManyField optional ist. Da dieses Feld als separate Tabelle statt als Datenbankspalte implementiert wird, ist null bedeutungslos. Der Wert von blank wird jedoch weiterhin Formulare beeinflussen und kontrollieren, ob die Validierung erfolgreich ist, wenn keine Beziehungen vorhanden sind.

• null=True, blank=False: Dies bedeutet, dass das Formular einen Wert erfordert, die Datenbank aber nicht. Dies ist möglicherweise die am wenigsten verwendete Konfiguration, es gibt jedoch einige Anwendungsfälle dafür:

  • Es ist völlig vernünftig, von Ihren Benutzern immer einen Wert zu verlangen, auch wenn er nicht tatsächlich von Ihrer Geschäftslogik benötigt wird. Schließlich sind Formulare nur eine Möglichkeit, Daten hinzuzufügen und zu bearbeiten. Sie haben möglicherweise Code, der Daten generiert, die nicht die gleiche strenge Validierung benötigen, die Sie von einem menschlichen Editor verlangen möchten.

  • Ein weiterer Anwendungsfall, den ich gesehen habe, ist, wenn Sie ein ForeignKey haben, für das Sie keine Kaskadenlöschung zulassen möchten. Das heißt, in der normalen Verwendung sollte die Beziehung immer vorhanden sein (blank=False), aber wenn das Objekt, auf das es verweist, gelöscht wird, möchten Sie nicht, dass dieses Objekt auch gelöscht wird. In diesem Fall können Sie null=True und on_delete=models.SET_NULL verwenden, um eine einfache Art der sanften Löschung zu implementieren.

Answer 4

Sie haben vielleicht Ihre Antwort, aber bis heute ist es schwierig zu beurteilen, ob null=True oder blank=True oder beides zu einem Feld hinzugefügt werden soll. Ich persönlich denke, es ist ziemlich nutzlos und verwirrend, so viele Optionen für Entwickler bereitzustellen. Lassen Sie sie die Nullen oder Leerstellen so behandeln, wie sie wollen.

Ich folge dieser Tabelle von Two Scoops of Django:

Answer 5

Wie im Django Model Field-Verweis gesagt: Link

Feldoptionen

Die folgenden Argumente sind für alle Feldtypen verfügbar. Alle sind optional.

null

Field.null

Wenn True, speichert Django leere Werte als NULL in der Datenbank. Standardmäßig ist False.

Vermeiden Sie die Verwendung von null bei feldbasierten Feldern wie CharField und TextField, da leere Zeichenfolgenwerte immer als leere Zeichenfolgen und nicht als NULL gespeichert werden. Wenn ein feldbasiertes Feld null=True hat, bedeutet das, dass es zwei mögliche Werte für "keine Daten" gibt: NULL und die leere Zeichenfolge. In den meisten Fällen ist es überflüssig, zwei mögliche Werte für "keine Daten" zu haben; Die Django-Konvention ist die Verwendung der leeren Zeichenfolge, nicht von NULL.

Sowohl für feldbasierte als auch für nicht feldbasierte Felder müssen Sie auch blank=True setzen, wenn Sie leere Werte in Formularen zulassen möchten, da der Parameter null sich nur auf die Datenbankspeicherung auswirkt (siehe blank).

Hinweis

Bei Verwendung des Oracle-Datenbank-Backends wird der Wert NULL gespeichert, um die leere Zeichenfolge zu kennzeichnen, unabhängig von diesem Attribut

blank

Field.blank

Wenn True, darf das Feld leer sein. Standardmäßig ist False.

Beachten Sie, dass dies sich von null unterscheidet. null betrifft ausschließlich die Datenbank, während blank sich auf die Validierung bezieht. Wenn ein Feld blank=True hat, wird die Formularvalidierung die Eingabe eines leeren Werts zulassen. Wenn ein Feld blank=False hat, ist das Feld erforderlich.