Question différencier null = True, vide = True dans django


Lorsque nous ajoutons un champ de base de données dans django, nous écrivons généralement models.CharField(max_length=100, null=True, blank=True). La même chose est faite avec ForeignKey, DecimalField etc. Quelle est la différence fondamentale en ayant

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

en ce qui concerne les différents (CharField, ForeignKey, ManyToManyField, DateTimeField) des champs. Quels sont les avantages / inconvénients de l'utilisation de 1/2/3?


619
2017-12-22 20:11


origine


Réponses:


null=True ensembles NULL (contre NOT NULL) sur la colonne de votre base de données. Valeurs vierges pour les types de champs Django tels que DateTimeField ou ForeignKey sera stocké comme NULL dans la DB.

blank=True détermine si le champ sera requis dans les formulaires. Cela inclut l'administrateur et vos propres formulaires personnalisés. Si blank=True alors le champ ne sera pas nécessaire, alors que si c'est False le champ ne peut pas être vide.

La combinaison des deux est si fréquente car généralement, si vous autorisez un champ à être vide dans votre formulaire, vous aurez également besoin de votre base de données pour autoriser NULL valeurs pour ce champ. L'exception est CharFieldle sable TextFields, qui dans Django sont jamais enregistré en tant que NULL. Les valeurs vides sont stockées dans le DB sous la forme d'une chaîne vide ('').

Quelques exemples:

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

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

De toute évidence, ces deux options n'ont pas de sens logique à utiliser (bien qu'il puisse y avoir un cas d'utilisation pour null=True, blank=False si vous voulez qu'un champ soit toujours requis dans les formulaires, mais facultatif quand vous traitez un objet à travers quelque chose comme le 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 et TEXT les types ne sont jamais enregistrés en tant que NULL par Django, donc null=True est inutile. Cependant, vous pouvez définir manuellement l'un de ces champs None forcer le définir comme NULL. Si vous avez un scénario où cela pourrait être nécessaire, vous devez toujours inclure null=True.


740
2017-12-22 20:35



Voici comment les cartes ORM blank & null champs pour 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)        

Les champs de base de données créés pour PostgreSQL 9.4 sont :

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

Les champs de base de données créés pour MySQL 5.6 sont :

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
)

75
2018-02-16 14:00



Comme indiqué dans la référence de Django Model Field: Lien

Options de champ

Les arguments suivants sont disponibles pour tous les types de champs. Tous sont optionnels.


null

Field.null

Si True, Django va stocker les valeurs vides NULL dans la base de données. Le défaut est False.

Évitez d'utiliser null sur des champs à base de chaînes tels que CharField et TextField parce que les valeurs de chaînes vides seront toujours stockées comme des chaînes vides, pas comme NULL. Si un champ basé sur une chaîne a null=True, cela signifie qu'il a deux valeurs possibles pour "pas de données": NULLet la chaîne vide. Dans la plupart des cas, il est redondant d'avoir deux valeurs possibles pour "pas de données"; la convention de Django est d'utiliser la chaîne vide, pas NULL.

Pour les champs basés sur des chaînes et non sur des chaînes, vous devrez également définir blank=True si vous souhaitez autoriser des valeurs vides dans les formulaires, null paramètre affecte uniquement le stockage de la base de données (voir blank).

Remarque

Lors de l'utilisation du backend de base de données Oracle, la valeur NULL sera stockée pour indiquer la chaîne vide indépendamment de cet attribut


blank

Field.blank 

Si True, le champ est autorisé à être vide. Le défaut est False.

Notez que ceci est différent de null. null est purement liée à la base de données, alors que blankest lié à la validation. Si un champ a blank=True, la validation de formulaire permettra l'entrée d'une valeur vide. Si un champ a blank=False, le champ sera requis.


17
2018-04-16 18:54



Simplement null=True définit la base de données devrait accepter NULL valeurs, d'autre part blank=True définit sur validation de formulaire ce champ doit accepter des valeurs vides ou non (si blank=True il accepte la forme sans valeur dans ce domaine et blank=False[valeur par défaut] sur la validation du formulaire, il montrera Ce champ est requis Erreur.

null=True/False lié à la base de données

blank=True/False lié à la validation de formulaire


15
2017-09-11 04:26



Quand on regarde les options dans une définition de modèle Django, il est crucial de comprendre qu'elles servent (au moins) à deux fins: la définition des tables de base de données, et la définition du format par défaut et la validation des formulaires modèles. (Je dis "par défaut" parce que les valeurs peuvent toujours être remplacées en fournissant un formulaire personnalisé.) Certaines options affectent la base de données, certaines options affectent les formulaires, et d'autres affectent les deux.

Quand cela vient à null et blank, d'autres réponses ont déjà montré que la première affecte la définition de la table de base de données et la dernière affecte la validation du modèle. Je pense que la distinction peut être rendue encore plus claire en examinant les cas d'utilisation pour les quatre configurations possibles:

  • null=False, blank=False: Ceci est la configuration par défaut et signifie que la valeur est requise dans toutes les circonstances.

  • null=True, blank=True: Cela signifie que le champ est facultatif dans toutes les circonstances. (Comme indiqué ci-dessous, cependant, c'est ne pas la méthode recommandée pour rendre facultatifs les champs basés sur des chaînes.)

  • null=False, blank=True: Cela signifie que le formulaire ne nécessite pas de valeur, contrairement à la base de données. Il y a un certain nombre de cas d'utilisation pour ceci:

    • L'utilisation la plus courante de cette configuration est pour les champs à base de chaînes optionnels. Comme noté dans la documentation, l'idiome de Django est d'utiliser la chaîne vide pour indiquer une valeur manquante. Si NULL On vous a également permis de vous retrouver avec deux façons différentes d'indiquer une valeur manquante, ce qui serait loin d'être idéal.

    • Une autre situation courante est que vous voulez calculer un champ automatiquement en fonction de la valeur d'un autre (dans votre save() méthode, disons). Vous ne voulez pas que l'utilisateur fournisse la valeur dans un formulaire (d'où blank=True), mais vous voulez que la base de données applique une valeur toujours fournie (null=False).

    • Une autre utilisation de cette configuration est quand vous voulez indiquer qu'un ManyToManyField est optionnel. Parce que ce champ est implémenté en tant que table distincte plutôt que colonne de base de données, null est sans signification. La valeur de blank Cela affectera quand même les formes, en contrôlant si la validation réussira quand il n'y a pas de relations.

  • null=True, blank=False: Cela signifie que le formulaire nécessite une valeur, mais pas la base de données. C'est peut-être la configuration la plus rarement utilisée, mais il y a quelques cas d'utilisation:

    • Il est parfaitement raisonnable d'exiger que vos utilisateurs incluent toujours une valeur même si elle n'est pas réellement requise par votre logique métier. Après tout, les formulaires ne sont qu'un moyen d'ajouter et d'éditer des données. Vous pouvez avoir du code qui génère des données qui n'ont pas besoin de la même validation stricte que vous voulez exiger d'un éditeur humain.

    • Un autre cas d'utilisation pour ce que j'ai vu est quand vous avez un ForeignKey pour lequel vous ne souhaitez pas autoriser suppression de cascade. C'est-à-dire qu'en usage normal la relation devrait toujours être là (blank=False), mais si la chose vers laquelle il pointe est supprimée, vous ne voulez pas que cet objet soit également supprimé. Dans ce cas, vous pouvez utiliser null=True et on_delete=models.SET_NULL mettre en œuvre un type simple de suppression douce.


6
2017-12-01 09:20



Voici un exemple de champ avec blank = true et null = true     description = models.TextField (vide = Vrai, null = Vrai)

Dans ce cas: blank = True: indique à notre formulaire qu'il est correct de laisser le champ de description vide

et

null = True: indique à notre base de données qu'il est correct d'enregistrer une valeur nulle dans notre champ db et de ne pas donner d'erreur.


1
2018-01-01 21:42



Quand on sauvegarde quelque chose dans l'admin Django, deux étapes de validation se passent, au niveau Django et au niveau de la base de données. Nous ne pouvons pas enregistrer de texte dans un champ numérique.

La base de données a le type de données NULL, ce n'est rien. Lorsque Django crée des colonnes dans la base de données, il spécifie qu'elles ne peuvent pas être vides. Et si vous essayez d'enregistrer NULL, vous obtiendrez l'erreur de base de données.

Aussi au niveau Django-Admin, tous les champs sont obligatoires par défaut, vous ne pouvez pas sauvegarder le champ vide, Django vous enverra une erreur.

Donc, si vous voulez enregistrer un champ vide, vous devez l'autoriser au niveau de Django et de la base de données. blank = True - autorisera le champ vide dans le panneau d'administration null = True - permettra d'enregistrer NULL dans la colonne de la base de données.


0
2018-05-11 23:58



Je pense que vous pourriez être intéressé par Sauvegardez les charField vides, nullables comme null plutôt que comme une chaîne vide. Il y a beaucoup de discussions à ce sujet, et un problème très pratique que vous pouvez rencontrer (par exemple, vous voulez ajouter une url openid pour chaque utilisateur qui peut être nul et devrait être unique).


0
2018-04-25 06:46