web-dev-qa-db-fra.com

différencier null = True, blank = 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 ForeignKeyname__, DecimalFieldetc. Quelle est la différence fondamentale entre avoir

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

en ce qui concerne différents champs (CharFieldname__, ForeignKeyname__, ManyToManyFieldname__, DateTimeFieldname__). Quels sont les avantages/inconvénients de l'utilisation de 1/2/3?

pythondjangodjango-models
750
user993563

null=True définit NULL(par rapport à NOT NULL) dans la colonne de votre base de données. Les valeurs vierges pour les types de champs Django tels que DateTimeFieldou ForeignKeyseront stockées sous le nom NULLdans la base de données.

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, le champ ne sera pas obligatoire, alors que s'il s'agit de Falsename__, le champ ne peut pas être vide.

La combinaison des deux est si fréquente car généralement, si vous laissez un champ vide dans votre formulaire, vous aurez également besoin de votre base de données pour autoriser les valeurs NULLpour ce champ. L'exception est CharFieldname__s et TextFieldname__s, qui, dans Django, sont jamais enregistrés sous le nom NULLname__. Les valeurs vides sont stockées dans la base de données sous forme de 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

Évidemment, ces deux options n’ont pas de sens logique à utiliser (cependant, il pourrait y avoir un cas d’utilisation pour null=True, blank=False si vous voulez qu'un champ soit toujours obligatoire dans les formulaires, mais facultatif lorsque vous traitez avec 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

Les types CHARet TEXTne sont jamais sauvegardés sous le nom NULLpar Django, de sorte que null=True est inutile. Toutefois, vous pouvez définir manuellement l'un de ces champs sur Noneafin de le forcer à NULLname__. Si vous avez un scénario où cela pourrait être nécessaire, vous devez toujours inclure null=True.

904
Chris Pratt

Voici comment l'ORM mappe les champs blank & null 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
)
94
user

Simplement null=True définit que la base de données doit accepter les valeurs NULL, tandis que blank=True définit lors de la validation du formulaire, ce champ doit accepter les valeurs vides ou non (Si blank=True il accepte le formulaire sans valeur dans ce champ et blank=False [valeur par défaut] lors de la validation du formulaire, il affichera - Ce champ est obligatoire erreur.

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

blank=True/False relatif à la validation du formulaire

20
Ranju R

Lorsque vous examinez les options d'une définition de modèle Django, il est essentiel de comprendre qu'elles remplissent (au moins) deux objectifs: définir les tables de la base de données et définir le format par défaut et valider les formulaires de modèle. (Je dis "par défaut" car les valeurs peuvent toujours être remplacées en fournissant un formulaire personnalisé.) Certaines options affectent la base de données, d'autres affectent les formulaires et d'autres affectent les deux.

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

  • null=False, blank=False: Il s'agit de 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, ceci n'est pas la méthode recommandée pour rendre les champs basés sur des chaînes facultatifs.)

  • null=False, blank=True: Cela signifie que le formulaire ne nécessite pas de valeur, mais que la base de données en a besoin. Il existe un certain nombre de cas d'utilisation pour cela:

    • L'utilisation la plus courante de cette configuration concerne les champs facultatifs basés sur des chaînes. Comme indiqué dans la documentation , l'idiome de Django consiste à utiliser la chaîne vide pour indiquer une valeur manquante. Si NULL était également autorisé, vous auriez deux façons différentes d'indiquer une valeur manquante.

    • Une autre situation courante est que vous souhaitez calculer un champ automatiquement en fonction de la valeur d'un autre (dans votre méthode save(), par exemple). 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 impose qu'une valeur est toujours fournie (null=False).

    • Une autre utilisation de cette configuration est lorsque vous souhaitez indiquer qu'un ManyToManyField est facultatif. Comme ce champ est implémenté sous forme de table distincte plutôt que de colonne de base de données, null n'a pas de sens . La valeur de blank continuera d’affecter les formulaires, cependant, en contrôlant si la validation aboutira ou non en l’absence de relations.

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

    • Il est parfaitement raisonnable de demander à vos utilisateurs d'inclure toujours une valeur même si cela n'est pas réellement requis par votre logique métier. Après tout, les formulaires ne sont qu’un moyen d’ajouter et de modifier des données. Vous avez peut-être un code qui génère des données qui n'exigent pas la validation stricte que vous souhaitez exiger d'un éditeur humain.

    • Un autre cas d’utilisation que j’ai vu est celui où vous avez un ForeignKey pour lequel vous ne souhaitez pas autoriser suppression en cascade . C'est-à-dire qu'en utilisation normale, la relation devrait toujours être là (blank=False), mais si la chose sur laquelle elle pointe est supprimée, vous ne souhaitez pas que cet objet soit également supprimé. Dans ce cas, vous pouvez utiliser null=True et on_delete=models.SET_NULL pour implémenter un type simple de suppression logicielle .

19
Kevin Christopher Henry

Vous pouvez avoir votre réponse, mais jusqu'à ce jour, il est difficile de juger s'il faut mettre null = True ou vide = True ou les deux à un champ. Personnellement, j'estime qu'il est assez inutile et déroutant de proposer autant de solutions aux développeurs. Laissez le gérer les null ou les blancs comme ils le souhaitent.

Je suis ce tableau: enter image description here

enter image description here

9
saran3h

Voici un exemple de champ avec blank= True et null=True

description = models.TextField (blank = True, null = True)

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 de base de données et de ne pas donner d'erreur.

8
Stryker
null = True

Signifie qu'il n'y a pas de contrainte de base de données pour que le champ soit rempli. Vous pouvez donc avoir un objet avec la valeur null pour le rempli qui a cette option.

blank = True

Cela signifie qu'il n'y a pas de contrainte de validation dans les formulaires Django. Ainsi, lorsque vous remplissez un modelFormpour ce modèle, vous pouvez laisser le champ avec cette option non remplie.

3
Milad Kh

Voici la différence principale entre null=True et blank=True:

La valeur par défaut de nullet blankest False. Ces deux valeurs fonctionnent au niveau du champ, c'est-à-dire si vous souhaitez conserver un champ nullou blankname__.

null=True définira la valeur du champ sur NULLi.e., no data. C'est fondamentalement pour la valeur de colonne des bases de données.

date = models.DateTimeField(null=True)

blank=True détermine si le champ sera requis dans les formulaires. Cela inclut l'administrateur et vos propres formulaires personnalisés.

title = models.CharField(blank=True) // title can be kept blank. Dans la base de données ("") sera stocké. null=Trueblank=True Cela signifie que le champ est facultatif dans toutes les circonstances.

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

Lorsque nous sauvegardons quelque chose dans l'administration Django, la validation en deux étapes se produit, au niveau de Django et au niveau de la base de données. Nous ne pouvons pas enregistrer du 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 de sauvegarder NULL, vous obtiendrez une erreur de base de données.

Également au niveau Django-Admin, tous les champs sont obligatoires par défaut, vous ne pouvez pas enregistrer les champs vides, 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 - autorisera l'enregistrement de NULL dans la colonne de la base de données.

2
Yuriy Kots

Il existe un point où null=True serait nécessaire même sur un CharField ou TextField et c'est lorsque la base de données a le drapeau unique défini pour la colonne.

En d'autres termes, si vous avez un Char/TextField unique dans Django, vous devez utiliser ceci:

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

Pour CharField ou TextField non uniques, il vaut mieux ignorer le null=True, sinon certains champs seront définis comme NULL alors que d'autres comme "" et vous devrez vérifier la valeur du champ pour NULL à chaque fois.

2
Nitin Nain

Je pense que vous pourriez être intéressé par enregistrez CharField vide, nullable comme null, plutôt que comme une chaîne vide . Il existe de nombreuses discussions à ce sujet et un problème très pratique que vous pouvez rencontrer (par exemple, vous souhaitez ajouter une URL openid pour chaque utilisateur, qui peut être null et doit être unique).

2
ramwin

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

pour 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.

hit upvote si vous le trouvez utile

1
Mohit Verma

Les valeurs par défaut de null et de blanc sont False.

Null: C'est lié à la base de données. Définit si une colonne de base de données donnée acceptera ou non les valeurs NULL.

Blanc: C'est lié à la validation. Il sera utilisé lors de la validation des formulaires, lors de l'appel de form.is_valid ().

Cela étant dit, il est parfaitement correct d'avoir un champ avec null = True et blank = False. Signification au niveau de la base de données, le champ peut être NULL, mais au niveau de l'application, il s'agit d'un champ obligatoire.

Désormais, la plupart des développeurs se trompent: Définition de null = True pour les champs basés sur des chaînes tels que CharField et TextField. Évitez de faire ça. Sinon, vous aurez deux valeurs possibles pour “pas de données”, à savoir: Aucun et une chaîne vide. Avoir deux valeurs possibles pour "pas de données" est redondant. La convention Django consiste à utiliser la chaîne vide, et non NULL.

0
sharif_42