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

C'est comment l'ORM cartes 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éé 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éé 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
)

Il est crucial de comprendre que les options dans un Django modèle de définition du champ de servir (au moins) deux objectifs: définir les tables de base de données, et de définir le format par défaut et la validation des modèles de formulaires. (Je dis "par défaut", parce que les valeurs peuvent toujours être remplacées par la fourniture d'un formulaire personnalisé.) Certains incidence sur les options de la base de données, certaines options affectent les formes, et certains touchent à la fois.

Quand il s'agit de null et blank, d'autres réponses ont déjà fait savoir que l'ancien affecte la base de données de définition de la table et celui-ci affecte la validation du modèle. Je pense que la distinction peut être encore plus clair en regardant des cas d'utilisation pour tous les quatre configurations possibles:

• null=False, blank=False: C'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, si, c'est pas la méthode recommandée pour effectuer la chaîne des champs facultatifs).

• null=False, blank=True: Cela signifie que la forme ne nécessite pas une valeur, mais la base de données. Il y a un certain nombre de cas d'utilisation pour ce:

  • L'utilisation la plus courante est facultatif chaîne des champs. Comme indiqué dans la documentation, le Django idiome est d'utiliser la chaîne vide pour indiquer une valeur manquante. Si NULL a également permis vous vous retrouvez avec deux méthodes différentes pour indiquer une valeur manquante.

  • Une autre commune de la situation, c'est que vous voulez calculer un champ automatiquement sur la base de la valeur de l'autre (dans votre save() méthode, par exemple). Vous ne voulez pas que l'utilisateur de fournir la valeur dans un formulaire (donc blank=True), mais vous ne voulez que la base de données pour appliquer qu'une valeur est toujours fourni (null=False).

  • Une autre utilisation, c'est quand vous voulez indiquer qu'une ManyToManyField est facultatif. Car ce champ est mis en œuvre comme un tableau distinct plutôt qu'une colonne de base de données, null est vide de sens. La valeur de blank affecte toujours les formes, bien que, de contrôler si oui ou non validation de la réussite quand il n'y a pas de relations.

• null=True, blank=False: Cela signifie que le formulaire exige une valeur, mais la base de données ne fonctionne pas. Cela peut être le plus rarement utilisé de la configuration, mais il existe des cas d'utilisation pour elle:

  • Il est parfaitement raisonnable de demander à vos utilisateurs de toujours inclure une valeur, même si elle n'est pas réellement requis par votre logique métier. Après tout, les formes ne sont qu'un moyen de l'ajout et l'édition de données. Vous pouvez avoir le code qui génère des données qui n'a pas besoin de la même rigueur de validation que vous souhaitez exiger d'un homme de l'éditeur.

  • Un autre cas d'utilisation que j'ai vu, c'est quand vous avez un ForeignKey pour lesquels vous ne souhaitez pas autoriser en cascade la suppression. C'est, en utilisation normale, la relation doit toujours être là (blank=False), mais si la chose il souligne arrive à être supprimé, vous ne voulez pas que cet objet d'être supprimés aussi. Dans ce cas, vous pouvez utiliser null=True et on_delete=models.SET_NULL à mettre en œuvre un simple genre de suppression logicielle.

Vous pouvez avoir votre réponse cependant jusqu'à ce jour il est difficile de juger de la possibilité de mettre null=True ou vide=True ou les deux, pour un champ. Personnellement, je pense que c'est assez inutile et source de confusion pour offrir de nombreuses options pour les développeurs. Laissez la gérer la nuls ou blancs mais ils veulent.

J'ai suivi ce tableau:

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

Ici, est la principale différence de null=True et blank=True:

La valeur par défaut de deux null et blank est Faux. Ces deux valeurs de travail sur le terrain, c'est à dire, si nous voulons garder un champ null ou blank.

null=True sera de définir la valeur du champ à NULL c'est à dire, pas de données. C'est fondamentalement pour les bases de données de la valeur de la colonne.

date = models.DateTimeField(null=True)

blank=True détermine si le champ est obligatoire dans les formulaires. Cela comprend l'admin et vos propres formulaires personnalisés.

title = models.CharField(blank=True) //title can be kept blank.
Dans la base de données ("") seront stockées.
null=True blank=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

Il y a 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 la unique drapeau de la colonne.

En d'autres termes, si vous avez un unique Char/TextField dans Django, vous aurez besoin d'utiliser cette:

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

Pour non-unique CharField ou TextField, vous serez mieux en sautant le null=True sinon certains champs aurez défini comme NULL alors que d'autres comme "" , et vous aurez à vérifier la valeur du champ pour la valeur NULL à chaque fois.

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 VIDE == 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.

frappé upvote si vous le trouvez utile