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 se fait avec ForeignKey
, DecimalField
etc. Quelle est la différence fondamentale
null=True
seulementblank=True
seulementnull=True
,blank=True
en ce qui concerne différents ( CharField
, ForeignKey
, ManyToManyField
, DateTimeField
champs). Quels sont les avantages / inconvénients de l'utilisation de 1/2/3?
python
django
django-models
user993563
la source
la source
ForeignKey
avecblank=True
, mais sansnull=True
. Lorsque le modèle est enregistré, je souhaite le "publier" automatiquement en créant une entrée publiée à partir de celui-ci. Je ne peux donc pas enregistrernull
dans la base de données, car chaque modèle doit être "publié", mais je veux pouvoir laisser le champ vide dans admin.Réponses:
null=True
définitNULL
(versusNOT NULL
) sur la colonne de votre base de données. Les valeurs vides pour les types de champs Django tels queDateTimeField
ouForeignKey
seront stockées commeNULL
dans la base de données.blank
détermine si le champ sera requis dans les formulaires. Cela inclut l'administrateur et vos formulaires personnalisés. Siblank=True
alors le champ ne sera pas requis, alors que si c'estFalse
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 les
NULL
valeurs de ce champ. L'exception estCharField
s etTextField
s, qui dans Django ne sont jamais enregistrés sousNULL
. Les valeurs vides sont stockées dans la base de données sous forme de chaîne vide (''
).Quelques exemples:
Évidemment, ces deux options n'ont pas de sens logique à utiliser (bien qu'il puisse y avoir un cas d'utilisation
null=True, blank=False
si vous souhaitez qu'un champ soit toujours requis dans les formulaires, facultatif lorsque vous traitez un objet via quelque chose comme le shell).CHAR
et lesTEXT
types ne sont jamais enregistrés commeNULL
par Django, c'est doncnull=True
inutile. Cependant, vous pouvez définir manuellement l'un de ces champsNone
pour forcer sa définition en tant queNULL
. Si vous avez un scénario où cela pourrait être nécessaire, vous devez toujours l'inclurenull=True
.la source
IntegrityError
s'affiche lorsque Django tente de sauvegarder l'enregistrement dans la base de données. Le champ ne doit pas être rempli par l'utilisateur, et c'est le problème car au niveau de la base de données, il n'est pas nul.CHAR
et neTEXT
soient JAMAIS enregistrés commeNULL
par Django". C'est vrai pour la plupart des backends, mais Oracle forcera une chaîne vide à NULL, donc le backend Django Oracle est une exception à la déclaration ci-dessus Django DocsNone
en Python) si vous définissez null = True. Les documents disent même d'éviter de définir null = True car cela autorise deux types différents de valeurs "vierges". Je viens de tester ce comportement avec Django 1.8 / MySQL 5.6blank=True
,null=False
,default="something"
?C'est ainsi que les cartes
blank
etnull
champs ORM pour Django 1.8Les champs de base de données créés pour PostgreSQL 9.4 sont:
Les champs de base de données créés pour MySQL 5.6 sont:
la source
blank
n'a aucun effet sur la base de données etnull
contrôle si la colonne de base de données autorise lesNULL
valeurs. Cette réponse est un très long chemin pour le dire et ne fournit aucune information utile à ce sujetblank
.blank
etnull
doit être reflété dans les colonnes de la base de données, alors qu'en fait ilblank
n'affecte que la gestion Python, pas les colonnes de la base de données. D'autres sont libres de voter s'ils le jugent utile; il est également possible pour les personnes induites en erreur par une réponse trompeuse de penser qu'elle était utile.Comme indiqué dans la référence du champ du modèle Django: Lien
la source
Il est essentiel de comprendre que les options d'une définition de champ de modèle Django servent (au moins) à deux fins: définir les tables de base de données, définir le format par défaut et valider les formulaires de modèle. (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 certaines affectent les deux.
En ce qui concerne
null
etblank
, d'autres réponses ont déjà précisé que la première affecte la définition de la table de base de données et la seconde affecte la validation du modèle. Je pense que la distinction peut être encore plus claire 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 en toutes circonstances.null=True
,blank=True
: Cela signifie que le champ est facultatif en toutes circonstances. (Comme indiqué ci-dessous, cependant, ce 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 la base de données en a besoin. Il existe un certain nombre de cas d'utilisation pour cela:L'utilisation la plus courante concerne les champs facultatifs basés sur des chaînes. Comme indiqué dans la documentation , l'idiome Django consiste à utiliser la chaîne vide pour indiquer une valeur manquante. Si
NULL
était également autorisé, vous vous retrouveriez avec deux façons différentes d'indiquer une valeur manquante.Une autre situation courante est que vous souhaitez calculer automatiquement un champ en fonction de la valeur d'un autre (dans votre
save()
méthode, 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 soit toujours fournie (null=False
).Une autre utilisation consiste à indiquer que a
ManyToManyField
est facultatif. Parce que ce champ est implémenté comme une table distincte plutôt que comme une colonne de base de données,null
n'a pas de sens . La valeur deblank
affectera toujours les formulaires, cependant, contrôlant si la validation réussira 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 moins fréquemment utilisée, mais il existe certains 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 de modifier 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 celle que vous souhaitez exiger d'un éditeur humain.
Un autre cas d'utilisation que j'ai vu est lorsque vous en avez un
ForeignKey
pour lequel vous ne souhaitez pas autoriser la suppression en cascade . C'est-à-dire qu'en utilisation normale, la relation devrait toujours être là (blank=False
), mais si la chose qu'elle pointe se trouve être supprimée, vous ne voulez pas que cet objet soit également supprimé. Dans ce cas, vous pouvez utilisernull=True
eton_delete=models.SET_NULL
implémenter un type simple de suppression logicielle .la source
Vous pouvez cependant avoir votre réponse jusqu'à ce jour, il est difficile de juger s'il faut mettre null = True ou blank = True ou les deux dans un champ. Personnellement, je pense qu'il est assez inutile et déroutant de fournir autant d'options aux développeurs. Laissez le gérer les valeurs nulles ou vides comme bon leur semble.
Je suis ce tableau, de Two Scoops of Django :
la source
Simplement
null=True
base de données doit accepter lesNULL
valeurs, d'autre partblank=True
définit lors de la validation du formulaire ce champ doit accepter les valeurs vides ou non (s'ilblank=True
accepte le formulaire sans valeur dans ce champ etblank=False
[valeur par défaut] lors de la validation du formulaire, il affichera ce champ est une erreur obligatoire .null=True/False
lié à la base de donnéesblank=True/False
liés à la validation des formulairesla source
Voici un exemple du champ avec
blank= True
etnull=True
description = models.TextField (vide = True, null = True)
Dans ce cas::
blank = True
indique à notre formulaire qu'il est autorisé de laisser le champ de description videet
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.la source
Signifie qu'il n'y a aucune contrainte de base de données pour le champ à remplir, vous pouvez donc avoir un objet avec une valeur nulle pour le rempli qui a cette option.
Signifie qu'il n'y a pas de contrainte de validation dans les formulaires django. donc lorsque vous remplissez un
modelForm
pour ce modèle, vous pouvez laisser le champ avec cette option vide.la source
Voici la principale différence de
null=True
etblank=True
:La valeur par défaut des deux
null
etblank
est False. Ces deux valeurs fonctionnent au niveau du champ, c'est-à-dire si nous voulons conserver un champnull
oublank
.null=True
définira la valeur du champ surNULL
ie, aucune donnée. Il s'agit essentiellement de la valeur de la colonne des bases 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.title = models.CharField(blank=True) // title can be kept blank.
Dans la base de données("")
sera stockée.null=True
blank=True
Cela signifie que le champ est facultatif en toutes circonstances.la source
Les valeurs par défaut null et blank sont False.
Null: il est lié à la base de données. Définit si une colonne de base de données donnée accepte ou non des valeurs nulles.
Vide: il 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 vide = 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.
Maintenant, là où la plupart des développeurs se trompent: Définir null = True pour les champs basés sur des chaînes tels que CharField et TextField. Évitez de faire ça. Sinon, vous finirez par avoir deux valeurs possibles pour «aucune donnée», c'est-à-dire: Aucune et une chaîne vide. Avoir deux valeurs possibles pour «aucune donnée» est redondant. La convention Django consiste à utiliser la chaîne vide, pas NULL.
la source
Lorsque nous enregistrons quoi que ce soit dans l'administrateur 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 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.
Toujours au niveau de Django-Admin, tous les champs sont obligatoires par défaut, vous ne pouvez pas enregistrer le champ vide, Django vous enverra une erreur.
Donc, si vous souhaitez 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 base de données.
la source
Il y a un point où
null=True
cela serait nécessaire même sur unCharField
ouTextField
et c'est quand la base de données a leunique
drapeau défini pour la colonne.En d'autres termes, si vous avez un Char / TextField unique dans Django, vous devrez utiliser ceci:
Pour CharField ou TextField non unique, vous feriez mieux de sauter le
null=True
sinon certains champs seront définis comme NULL tandis que d'autres comme "", et vous devrez vérifier la valeur du champ pour NULL à chaque fois.la source
null est pour la base de données et vide est pour la validation des champs que vous souhaitez afficher sur l'interface utilisateur comme textfield pour obtenir le nom de famille de la personne. Si lastname = models.charfield (blank = true), il n'a pas demandé à l'utilisateur d'entrer le nom de famille car c'est le champ optionnel maintenant. Si lastname = models.charfield (null = true), cela signifie que si ce champ n'obtient aucune valeur de l'utilisateur, il sera stocké dans la base de données sous la forme d'une chaîne vide "".
la source
La signification de null = True et blank = True dans le modèle dépend également de la façon dont ces champs ont été définis dans la classe de formulaire.
Supposons que vous ayez défini la classe suivante:
Si la classe de formulaire a été définie comme ceci:
Ensuite, le champ «nom» ne sera pas obligatoire (en raison du blanc = vrai dans le modèle) et le champ «adresse» sera obligatoire (en raison du blanc = faux dans le modèle).
Cependant, si la classe ClientForm a été définie comme ceci:
Ensuite, les deux champs ('nom' et 'adresse') seront obligatoires, "puisque les champs définis de manière déclarative sont laissés tels quels " ( https://docs.djangoproject.com/en/3.0/topics/forms/modelforms/ ) , c'est-à-dire que la valeur par défaut pour l'attribut 'required' du champ de formulaire est True et cela nécessitera que les champs 'name' et 'address' soient remplis, même si, dans le modèle, le champ a été défini sur blank = True.
la source
null - la valeur par défaut est False si True, Django stockera vide comme null dans la base de données.
vide - la valeur par défaut est False si vrai, ce champ peut être vide
plus, allez à https://docs.djangoproject.com/en/3.0/topics/db/models/
la source
Ce tableau ci-dessous illustre les principales différences:
la source
En termes très simples ,
Le blanc est différent de null.
null est purement lié à la base de données , alors que blank est lié à la validation (requis dans le formulaire) .
Si
null=True
, Django le ferastore empty values as NULL in the database
. Si un champ l'ablank=True
, la validation du formulaire le seraallow entry of an empty value
. Si un champ a vide = False, le champ sera obligatoire.la source