differenziere null = Wahr, leer = Wahr in django

So ordnet der ORM blank & null Felder für Django 1.8 zu

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
)

Wie in Django Modellfeldreferenz gesagt: Link

Feldoptionen

Die folgenden Argumente stehen allen Feldtypen zur Verfügung. Alle sind optional.

null

Field.null

Wenn True, speichert Django leere Werte als NULL in der Datenbank. Die Standardeinstellung ist False.

Vermeiden Sie die Verwendung von null für zeichenfolgenbasierte Felder wie CharField und TextField, da leere Zeichenfolgenwerte immer als leere Zeichenfolgen und nicht als NULL gespeichert werden. Wenn ein auf Zeichenfolgen basierendes Feld null=True enthält, bedeutet dies, dass es zwei mögliche Werte für "keine Daten" enthält: 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 besteht darin, die leere Zeichenfolge zu verwenden, nicht NULL.

Für sowohl zeichenfolgenbasierte als auch nicht zeichenfolgenbasierte Felder müssen Sie auch blank=True festlegen, wenn Sie leere Werte in Formularen zulassen möchten, da sich der Parameter null nur auf den Datenbankspeicher auswirkt (siehe blank).

Hinweis

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

blank

Field.blank

Bei True darf das Feld leer sein. Die Standardeinstellung ist False.

Beachten Sie, dass dies anders ist als null. null ist rein datenbankbezogen, während blank validierungsbezogen ist. Wenn ein Feld blank=True enthält, kann bei der Formularüberprüfung ein leerer Wert eingegeben werden. Wenn ein Feld blank=False enthält, ist das Feld erforderlich.

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

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

• 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 die empfohlene Methode, um zeichenfolgenbasierte Felder optional zu machen.)

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

  • Am häufigsten werden optionale, auf Zeichenfolgen basierende Felder verwendet. Wie in der Dokumentation vermerkt soll das Django-Idiom die leere Zeichenfolge verwenden, um einen fehlenden Wert anzuzeigen. Wenn NULL ebenfalls zulässig wäre, hätten Sie zwei verschiedene Möglichkeiten, um einen fehlenden Wert anzugeben.

  • Eine andere häufige Situation ist, dass Sie ein Feld automatisch auf der Grundlage des Werts eines anderen Felds berechnen möchten (beispielsweise 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 angegeben wird (null=False).

  • Eine andere Verwendung ist, wenn Sie angeben möchten, dass ManyToManyField optional ist. Da dieses Feld als separate Tabelle und nicht als Datenbankspalte implementiert ist, ist null bedeutungslos . Der Wert von blank wirkt sich weiterhin auf Formulare aus, wobei gesteuert wird, 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 ist möglicherweise die am seltensten verwendete Konfiguration, es gibt jedoch einige Anwendungsfälle:

  • Es ist durchaus sinnvoll, von Ihren Benutzern zu verlangen, dass sie immer einen Wert angeben, auch wenn dies von Ihrer Geschäftslogik nicht tatsächlich verlangt wird. Formulare sind schließlich nur eine Möglichkeit, Daten hinzuzufügen und zu bearbeiten. Möglicherweise haben Sie Code, der Daten generiert, für die nicht die gleiche strenge Überprüfung erforderlich ist, die Sie von einem menschlichen Editor fordern möchten.

  • Ein anderer Anwendungsfall, den ich gesehen habe, ist, wenn Sie ein ForeignKey haben, für das Sie nicht zulassen möchten Kaskadenlöschung . Das heißt, im normalen Gebrauch sollte die Relation immer vorhanden sein (blank=False), aber wenn das Objekt, auf das sie zeigt, gelöscht wird, möchten Sie nicht, dass auch dieses Objekt gelöscht wird. In diesem Fall können Sie null=True und on_delete=models.SET_NULL verwenden, um eine einfache Art von soft deletion zu implementieren.

Einfach null=True definiert, dass die Datenbank NULL Werte akzeptieren soll, andererseits blank=True definiert, dass bei der Formularüberprüfung dieses Feld leere Werte akzeptieren soll oder nicht (Wenn blank=True Formular ohne Wert akzeptieren soll in diesem Feld und blank=False [Standardwert] bei der Formularüberprüfung wird Dieses Feld ist erforderlich Fehler angezeigt.

null=True/False bezogen auf die Datenbank

blank=True/False im Zusammenhang mit der Formularüberprüfung

Möglicherweise haben Sie Ihre Antwort, aber bis heute ist es schwierig zu beurteilen, ob in einem Feld null = Wahr oder leer = Wahr oder beides steht. Ich persönlich finde es ziemlich nutzlos und verwirrend, Entwicklern so viele Optionen zur Verfügung zu stellen. Lassen Sie die Nullen oder Leerzeichen behandeln, wie sie wollen.

Ich folge dieser Tabelle:

Hier ist ein Beispiel für das Feld mit blank= True und null=True

description = models.TextField (leer = wahr, null = wahr)

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 unser DB-Feld aufzunehmen und keinen Fehler zu melden.

null = True

Bedeutet, dass für das auszufüllende Feld keine Datenbankbeschränkung besteht. Sie können also ein Objekt mit einem Nullwert für das ausgefüllte Feld mit dieser Option haben.

blank = True

Bedeutet, dass es in Django Formularen keine Einschränkung der Validierung gibt. Wenn Sie also ein modelForm für dieses Modell eingeben, können Sie das Feld mit dieser Option nicht ausgefüllt lassen.

Hier ist der Hauptunterschied von null=True und blank=True:

Der Standardwert von null und blank ist False. Diese beiden Werte funktionieren auf Feldebene, d. H. Ob wir ein Feld null oder blank behalten möchten.

null=True setzt den Feldwert auf NULL, d. H. Keine Daten. Grundsätzlich gilt dies für den Datenbankspaltenwert.

date = models.DateTimeField(null=True)

blank=True legt fest, ob das Feld in Formularen benötigt wird. Dies schließt den Administrator und Ihre eigenen benutzerdefinierten Formulare ein.

title = models.CharField(blank=True) // title can be kept blank. In der Datenbank wird ("") gespeichert. null=Trueblank=True Dies bedeutet, dass das Feld unter allen Umständen optional ist.

epic = models.ForeignKey(null=True, blank=True)
// The exception is CharFields() and TextFields(), which in Django are never saved as NULL. Blank values a

Wenn wir irgendetwas in Django admin speichern, geschieht die Validierung in zwei Schritten, auf Ebene Django und auf Datenbankebene. Wir können keinen Text in einem Zahlenfeld speichern.

Die Datenbank hat den Datentyp NULL, es ist nichts. Wenn Django Spalten in der Datenbank erstellt, gibt dies an, dass diese nicht leer sein dürfen. Und wenn Sie versuchen, NULL zu speichern, erhalten Sie den Datenbankfehler.

Auch auf Django-Admin-Ebene sind standardmäßig alle Felder erforderlich. Sie können kein leeres Feld speichern. Django gibt einen Fehler aus.

Wenn Sie ein leeres Feld speichern möchten, müssen Sie es auf Django- und Datenbankebene zulassen. blank = True - erlaubt leeres Feld im Admin-Panel null = True - erlaubt das Speichern von NULL in der Datenbankspalte.

Es gibt einen Punkt, an dem null=True sogar für CharField oder TextField erforderlich wäre, und in diesem Fall ist für die Spalte in der Datenbank das Flag unique gesetzt.

Mit anderen Worten, wenn Sie ein eindeutiges Char/TextField in Django haben, müssen Sie dies verwenden:

models.CharField(blank=True, null=True, unique=True)

Bei nicht eindeutigem CharField oder TextField ist es besser, den null=True zu überspringen, da ansonsten einige Felder als NULL und andere als "" festgelegt werden und Sie den Feldwert jedes Mal auf NULL überprüfen müssen.

Ich denke, Sie könnten interessiert sein an Speichern Sie leere, nullfähige CharFields als null anstatt als leere Zeichenkette . Es gibt viele Diskussionen darüber und ein sehr praktisches Problem, auf das Sie stoßen können (z. B. Sie möchten eine OpenID-URL für jeden Benutzer hinzufügen, die null sein kann und eindeutig sein sollte).

für NULL == TRUE

    The default value of both null and blank is False. Both of these values work
 at field level i.e., whether we want to keep a field null or blank.

        null=True will set the field’s value to NULL i.e., no data. It is 
basically for the databases column value.


        date = models.DateTimeField(null=True)

für BLANK == TRUE

    blank=True determines whether the field will be required in forms. This 
includes the admin and your own custom forms.

    title = models.CharField(blank=True) // title can be kept blank. In the 
database ("") will be stored.

drücke upvote, wenn du es hilfreich findest

Die Standardwerte für null und leer sind False.

Null: Es ist datenbankbezogen. Definiert, ob eine bestimmte Datenbankspalte Nullwerte akzeptiert oder nicht.

Leer: Es ist validierungsbezogen. Es wird während der Formularüberprüfung verwendet, wenn form.is_valid () aufgerufen wird.

Davon abgesehen ist es vollkommen in Ordnung, ein Feld mit null = wahr und leer = falsch zu haben. Auf Datenbankebene kann das Feld NULL sein, auf Anwendungsebene ist es jedoch ein Pflichtfeld.

Jetzt, wo die meisten Entwickler etwas falsch machen: Definieren von null = True für zeichenfolgenbasierte Felder wie CharField und TextField. Vermeiden Sie das. Andernfalls erhalten Sie zwei mögliche Werte für "keine Daten", dh Keine und eine leere Zeichenfolge. Zwei mögliche Werte für "keine Daten" sind redundant. Die Django -Konvention besteht darin, die leere Zeichenfolge zu verwenden, nicht NULL.