• 2.2
  • dev
  • Version de la documentation : 3.0

Référence des contraintes

New in Django 2.2.

Les classes définies dans ce module créent des contraintes de base de données. Elles sont ajoutées dans l’option Meta.constraints des modèles.

Référencement des contraintes intégrées

Les contraintes sont définies dans django.db.models.constraints, mais par commodité elles sont importées dans django.db.models. La convention standard est d’utiliser from django.db import models et de se référer aux contraintes avec models.<Telle>Constraint.

Contraintes dans les classes de base abstraites

Les contraintes doivent toujours être nommées de façon unique. Cela signifie qu’il n’est pas possible de définir des contraintes dans une classe de base abstraite, dans la mesure où l’option Meta.constraints est héritée par les sous-classes avec exactement les mêmes valeurs d’attributs (y compris name). Pour éviter des collisions de nom, le nom peut contenir '%(app_label)s'``et ``'%(class)s' qui seront remplacés respectivement par l’étiquette de l’application et le nom de la classe du modèle concret (tout en minuscules). Par exemple, CheckConstraint(check=Q(age__gte=18), name='%(app_label)s_%(class)s_is_adult').

Validation des contraintes

En général, les contraintes ne sont pas vérifiées lors de full_clean() et ne produisent donc pas d’erreurs ValidationError. Par contre, vous obtiendrez une erreur d’intégrité de base de données lors de l’enregistrement save(). Les contraintes UniqueConstraint sans condition (c’est-à-dire les contraintes d’unicité non partielles) sont différentes à cet égard dans le sens où elles font appel à la logique existante validate_unique() et recourent donc à la validation en deux étapes. En plus de l’erreur IntegrityError au moment du save(), des erreurs ValidationError sont aussi produites lors de la validation du modèle si la contrainte UniqueConstraint n’est pas respectée.

CheckConstraint

class CheckConstraint(*, check, name)

Crée une contrainte de vérification dans la base de données.

check

CheckConstraint.check

Un objet Q qui indique le contrôle que la contrainte souhaitée doit appliquer.

Par exemple, CheckConstraint(check=Q(age__gte=18), name='age_gte_18') s’assure que le champ age n’est jamais au-dessous de 18.

name

CheckConstraint.name

The name of the constraint. You must always specify a unique name for the constraint.

Changed in Django 3.0:

L’interpolation des variables '%(app_label)s' et '%(class)s' a été ajoutée.

UniqueConstraint

class UniqueConstraint(*, fields, name, condition=None)

Crée une contrainte d’unicité dans la base de données.

fields

UniqueConstraint.fields

Une liste de noms de champs qui précise l’ensemble unique de colonnes pour lesquelles la contrainte va assurer l’unicité.

Par exemple, UniqueConstraint(fields=['chambre', 'date'], name='reservation_unique') s’assure que chaque chambre ne peut être réservée qu’une seule fois par date.

name

UniqueConstraint.name

The name of the constraint. You must always specify a unique name for the constraint.

Changed in Django 3.0:

L’interpolation des variables '%(app_label)s' et '%(class)s' a été ajoutée.

condition

UniqueConstraint.condition

Un objet Q qui indique la condition que la contrainte souhaitée doit appliquer.

Par exemple :

UniqueConstraint(fields=['user'], condition=Q(status='DRAFT'), name='unique_draft_user')

s’assure que chaque utilisateur dispose d’un seul brouillon.

Ces conditions sont soumises aux même restrictions de base de données que Index.condition.

Back to Top