python - link - django tutorial




Unterscheiden null=True, leer=True in Django (6)

Wenn wir ein Datenbankfeld 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 beim Haben DecimalField

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

in Bezug auf verschiedene CharField ( CharField , ForeignKey , ManyToManyField , DateTimeField ). Was sind die Vorteile / Nachteile der Verwendung von 1/2/3?


Einfach null=True definiert Datenbank sollte akzeptieren NULL Werte, andererseits blank=True definiert bei der Formularüberprüfung sollte dieses Feld leere Werte akzeptieren oder nicht (Wenn blank=True akzeptiert es Formular ohne einen Wert in diesem Feld und blank=False [Standardwert ] Bei der Formularvalidierung wird angezeigt, dass dieses Feld ein erforderlicher Fehler ist.

null=True/False bezogen auf die Datenbank

blank=True/False Bezug auf Formularvalidierung


Hier ist ein Beispiel für das Feld mit blank = true und null = true description = models.TextField (leer = True, null = True)

In diesem Fall: blank = True: teilt unserem Formular mit, dass es in Ordnung ist, das Beschreibungsfeld leer zu lassen

und

null = True: teilt unserer Datenbank mit, dass es in Ordnung ist, einen Nullwert in unserem db-Feld aufzuzeichnen und keinen Fehler zu geben.


So bildet das ORM blank und null für Django 1.8 ab

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 für PostgreSQL 9.4 erstellten Datenbankfelder 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
)

Wenn Sie sich die Optionen in einer Django-Modelldefinition ansehen, ist es wichtig zu verstehen, dass sie (mindestens) zwei Zwecken dienen: Definieren der Datenbanktabellen und Definieren des Standardformats und der Validierung von Modellformularen. (Ich sage "Standard", da die Werte immer überschrieben werden können, indem ein benutzerdefiniertes Formular bereitgestellt wird.) Einige Optionen wirken sich auf die Datenbank aus, einige Optionen wirken sich auf Formulare aus und einige beeinflussen beide.

Wenn es zu null und blank , haben andere Antworten bereits deutlich gemacht, dass ersteres die Definition der Datenbanktabelle beeinflusst und letzteres die Modellvalidierung beeinflusst. Ich denke, die Unterscheidung kann noch deutlicher gemacht werden, wenn man die Anwendungsfälle für alle vier möglichen Konfigurationen betrachtet:

  • 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 string-basierte Felder optional zu machen.)

  • null=False , blank=True : Dies bedeutet, dass das Formular keinen Wert erfordert, die Datenbank jedoch. Hierfür gibt es eine Reihe von Anwendungsfällen:

    • Die häufigste Verwendung dieser Konfiguration ist für optionale string-basierte Felder. Wie in der Dokumentation erwähnt , verwendet das Django-Idiom die leere Zeichenfolge, um einen fehlenden Wert anzugeben. Wenn NULL auch erlaubt wäre, würden Sie zwei verschiedene Möglichkeiten haben, einen fehlenden Wert anzugeben, was weniger als ideal wäre.

    • Eine andere häufige Situation ist, dass Sie ein Feld automatisch basierend auf dem Wert eines anderen berechnen möchten save() . B. in Ihrer save() -Methode). Sie möchten nicht, dass der Benutzer den Wert in einem Formular angibt (daher blank=True ), aber Sie möchten, dass die Datenbank erzwingt, dass immer ein Wert bereitgestellt wird ( null=False ).

    • Eine weitere Verwendung dieser Konfiguration ist, wenn Sie angeben möchten, dass ein ManyToManyField optional ist. Da dieses Feld als separate Tabelle und nicht als Datenbankspalte implementiert ist, ist null bedeutungslos . Der Wert von blank jedoch immer noch auf Formulare aus, um zu steuern, ob die Validierung erfolgreich ist, wenn keine Beziehungen vorhanden sind.

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

    • Es ist durchaus sinnvoll, von Ihren Benutzern zu verlangen, dass sie immer einen Wert angeben, auch wenn dies von Ihrer Geschäftslogik eigentlich nicht gefordert wird. Denn Formulare sind nur eine Möglichkeit, Daten hinzuzufügen und zu bearbeiten. Sie haben möglicherweise Code, der Daten generiert, die nicht die gleiche strenge Validierung erfordern, die Sie von einem menschlichen Editor benötigen.

    • Ein weiterer Anwendungsfall, den ich gesehen habe, ist, wenn Sie einen ForeignKey für den Sie keine Kaskadenlöschung zulassen möchten. Das heißt, im normalen Gebrauch sollte die Beziehung immer da sein ( blank=False ), aber wenn das Ding, auf das es zeigt, gelöscht wird, wollen Sie auch nicht, dass dieses Objekt gelöscht wird. In diesem Fall können Sie null=True und on_delete=models.SET_NULL , um eine einfache Art des weichen Löschens zu implementieren.


Wie in Django Model Field erwähnt: 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. Standard ist False .

Vermeiden Sie die Verwendung von null für string-basierte Felder wie CharField und TextField da leere Zeichenfolgenwerte immer als leere Zeichenfolgen und nicht als NULL gespeichert werden. Wenn ein stringbasiertes Feld null=True hat, bedeutet dies, 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 verwendet den leeren String, nicht NULL .

Für Felder, die auf Zeichenfolgen basieren und nicht auf Zeichenfolgen basieren, müssen Sie außerdem blank=True festlegen, wenn Sie leere Werte in Formularen zulassen möchten, da der null Parameter nur den Datenbankspeicher betrifft (siehe blank ).

Hinweis

Wenn Sie das Oracle-Datenbank-Back-End verwenden, wird der Wert NULL gespeichert, um unabhängig von diesem Attribut die leere Zeichenfolge anzugeben


blank

Field.blank

Wenn True , darf das Feld leer sein. Standard ist False .

Beachten Sie, dass dies anders als null . null ist rein datenbankbezogen, während blank die Validierung bezogen ist. Wenn ein Feld blank=True , erlaubt die Formularüberprüfung die Eingabe eines leeren Wertes. Wenn ein Feld blank=False , wird das Feld benötigt.


null ist für den DataBase-Spaltenwert

null=True setzt NULL (im Gegensatz zu NOT NULL ) für die Spalte in Ihrem DB. Leere Werte für Django-Feldtypen wie DateTimeField oder ForeignKey werden im DB als NULL gespeichert.

blank ist für die Feldanforderung in Formularen

blank=True legt fest, ob das Feld in Formularen benötigt wird. Dies beinhaltet den Admin und Ihre eigenen benutzerdefinierten Formulare. Wenn blank=True wird das Feld nicht benötigt, wenn es False das Feld nicht leer sein.

Die Kombination der beiden ist so häufig, weil Sie in der Regel, wenn Sie zulassen, dass ein Feld in Ihrem Formular leer ist, Ihre Datenbank auch NULL Werte für dieses Feld zulassen müssen. Die Ausnahme sind CharField und TextField , die in Django niemals als NULL gespeichert werden. Leerwerte werden im DB als leere Zeichenfolge ( '' ) gespeichert.

Ein paar Beispiele:

models.DateTimeField(blank=True) # raises IntegrityError if blank

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

Offensichtlich sind diese beiden Optionen logisch nicht sinnvoll (obwohl es einen Anwendungsfall für null=True, blank=False wenn ein Feld immer in Formularen erforderlich sein soll, aber optional, wenn es sich um ein Objekt handelt wie die Schale.)

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

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

CHAR und TEXT Typen werden niemals von Django als NULL gespeichert, daher ist null=True unnötig. Sie können jedoch eines dieser Felder manuell auf None festlegen, um die Erzwingung als NULL zu erzwingen. Wenn Sie ein Szenario benötigen, in dem dies erforderlich sein könnte, sollten Sie weiterhin null=True einschließen.







django-models