---
title: "Référence des contraintes"
version: 3.1
locale: fr
source: https://docs.djangoproject.com/fr/3.1/ref/models/constraints/
canonical: https://djangodocs.dev/fr/3.1/ref/models/constraints/
---
# 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`](/fr/3.1/ref/models/options/#django.db.models.Options.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`](/fr/3.1/topics/db/models/#module-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`](/fr/3.1/ref/models/options/#django.db.models.Options.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`](#django.db.models.UniqueConstraint.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(* (Keyword-only parameters separator (PEP 3102)), check, name)`

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

### `check`

#### `CheckConstraint.check`

Un objet [`Q`](/fr/3.1/ref/models/querysets/#django.db.models.Q) ou une [`Expression`](/fr/3.1/ref/models/expressions/#django.db.models.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`](/fr/3.1/ref/models/expressions/#django.db.models.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(* (Keyword-only parameters separator (PEP 3102)), 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`](/fr/3.1/ref/models/querysets/#django.db.models.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`](/fr/3.1/ref/models/indexes/#django.db.models.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.

> **Warning**
>
> Les contraintes d’unicité différées peuvent amener à des [performances réduites](https://www.postgresql.org/docs/current/sql-createtable.html#id-1.9.3.85.9.4).