# Documentation Django 3.1.9.dev

# Référence des contraintes

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` ou une `Expression` booléenne 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.

Changed in Django 3.1:

La prise en charge des `Expression` booléennes a été ajoutée.

### `name`

`CheckConstraint.``name`

Le nom de la contrainte. La contrainte doit toujours posséder un nom unique.

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, deferrable=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`

Le nom de la contrainte. La contrainte doit toujours posséder un nom unique.

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

### `deferrable`

`UniqueConstraint.``deferrable`

New in Django 3.1.

Définissez ce paramètre pour créer une contrainte d’unicité différable. Les valeurs acceptées sont `Deferrable.DEFERRED` ou `Deferrable.IMMEDIATE`. Par exemple

    from django.db.models import Deferrable, UniqueConstraint

    UniqueConstraint(
        name='unique_order',
        fields=['order'],
        deferrable=Deferrable.DEFERRED,
    )

Par défaut, les contraintes ne sont pas différées. Une contrainte différée ne sera pas appliquée avant la fin de la transaction. Une contrainte immédiate sera appliquée immédiatement après chaque commande.

MySQL, MariaDB et SQLite.

Les contraintes d’unicité différables sont ignorées avec MySQL, MariaDB et SQLite car ces moteurs ne les prennent pas en charge.

Avertissement

Les contraintes d’unicité différées peuvent amener à des performances réduites.