L'une des options de champ souvent utilisées lors de la rédaction de modèles dans Django est blank=True et null=True. Les deux options permettent de laisser un champ vide, mais leur objectif et leur fonctionnement réel diffèrent. Dans cet article, nous allons expliquer ce que signifie chaque option, leurs différences, et comment et quand les utiliser.


1. blank=True

L'option blank=True détermine si un champ peut être laissé vide lors de la validation du formulaire. Cela concerne principalement les formulaires de Django.

  • Signification : Cela permet d'éviter des erreurs de validation dans le formulaire si le champ est vide.
  • Situation d'utilisation : Utilisé lorsque vous souhaitez permettre qu'un champ soit vide lors de la saisie de données par un utilisateur. Par exemple, si un champ dans les informations de profil d'un utilisateur n'est pas obligatoire et peut ne pas être rempli, on utilise blank=True.
from django.db import models

class Profile(models.Model):
    bio = models.TextField(blank=True)  # Champ de biographie non obligatoire

2. null=True

null=True permet que la valeur de ce champ soit NULL dans la base de données. Cela détermine si une valeur vide est autorisée au niveau de la base de données.

  • Signification : Cela permet au champ d'avoir une valeur NULL dans la base de données.
  • Situation d'utilisation : Utilisé lorsque vous devez gérer les cas où une valeur est vide lors de la sauvegarde dans la base de données. Dans le cas où le champ n'est pas une chaîne, si null=True n'est pas spécifié, Django enregistrera une valeur par défaut au lieu d'une valeur vide. Par exemple, si vous souhaitez que le champ d'une date ou d'un nombre soit NULL lorsqu'il n'y a pas de valeur, vous devez définir null=True.
from django.db import models

class Event(models.Model):
    end_date = models.DateTimeField(null=True)  # Champ pour un événement sans date de fin

3. Différences entre blank=True et null=True

La principale différence entre les deux options concerne la validation du formulaire et la façon dont les données sont enregistrées dans la base de données.

Option Description de la fonctionnalité Objectif d'utilisation
blank=True Permet de laisser le champ vide lors de la validation du formulaire Ne rend pas l'entrée utilisateur obligatoire
null=True Permet de laisser une valeur NULL dans la base de données Permet de laisser le champ vide dans la base de données

On peut considérer que blank=True permet un vide au niveau du formulaire, tandis que null=True autorise un vide au niveau de la base de données.


4. Quand utiliser les deux options ensemble ?

Généralement, pour les champs de chaîne (CharField, TextField, etc.), on définit uniquement blank=True et on n'utilise pas null=True. Django ne traite pas les chaînes vides ('') et les valeurs NULL comme des entités distinctes ; il est habituel que les chaînes vides soient traitées comme des valeurs vides au lieu de NULL.

En revanche, pour les champs non textuels (par exemple : DateTimeField, IntegerField), si le champ n'est pas obligatoire, il est préférable d'utiliser blank=True et null=True ensemble. Cela permet de laisser le champ vide dans le formulaire et de stocker une valeur NULL dans la base de données.

class Task(models.Model):
    name = models.CharField(max_length=200, blank=True)   # Seulement blank=True pour les champs de chaîne
    due_date = models.DateTimeField(blank=True, null=True) # Les champs de date utilisent both blank=True et null=True

5. Résumé et conclusion

  • blank=True : Permet au champ d'être vide sans provoquer d'erreurs dans le formulaire. Utilisé principalement lorsque l'entrée utilisateur n'est pas obligatoire.
  • null=True : Permet au champ d'avoir une valeur NULL dans la base de données. Utilisé pour les champs non textuels.
  • Utilisation conjointe : Utilisé pour les champs non textuels où les valeurs peuvent être laissées vides optionnellement en utilisant blank=True et null=True ensemble.

En tirant parti de ces deux options lors de la conception des modèles Django, vous pouvez améliorer la flexibilité de la structure de la base de données et des entrées utilisateur.

Dans le prochain article, nous examinerons l'option de champ related_name, souvent utilisée lors de la configuration de ForeignKey. C'est également une option très utile dans l'ORM, alors ne manquez pas notre prochain article.