---
title: "Constraints reference"
version: 3.0
locale: pt-br
source: https://docs.djangoproject.com/pt-br/3.0/ref/models/constraints/
canonical: https://djangodocs.dev/pt-br/3.0/ref/models/constraints/
---
# Constraints reference

> **New in Django 2.2**

The classes defined in this module create database constraints. They are added
in the model [`Meta.constraints`](/pt-br/3.0/ref/models/options/#django.db.models.Options.constraints)
option.

> **Referencing built-in constraints**
>
> Constraints are defined in `django.db.models.constraints`, but for
> convenience they’re imported into [`django.db.models`](/pt-br/3.0/topics/db/models/#module-django.db.models). The standard
> convention is to use `from django.db import models` and refer to the
> constraints as `models.<Foo>Constraint`.

> **Constraints in abstract base classes**
>
> You must always specify a unique name for the constraint. As such, you
> cannot normally specify a constraint on an abstract base class, since the
> [`Meta.constraints`](/pt-br/3.0/ref/models/options/#django.db.models.Options.constraints) option is
> inherited by subclasses, with exactly the same values for the attributes
> (including `name`) each time. To work around name collisions, part of the
> name may contain `'%(app_label)s'` and `'%(class)s'`, which are
> replaced, respectively, by the lowercased app label and class name of the
> concrete model. For example `CheckConstraint(check=Q(age__gte=18),
> name='%(app_label)s_%(class)s_is_adult')`.

> **Validation of Constraints**
>
> In general constraints are **not** checked during `full_clean()`, and do
> not raise `ValidationError`s. Rather you’ll get a database integrity
> error on `save()`. `UniqueConstraint`s without a
> [`condition`](#django.db.models.UniqueConstraint.condition) (i.e. non-partial unique constraints)
> are different in this regard, in that they leverage the existing
> `validate_unique()` logic, and thus enable two-stage validation. In
> addition to `IntegrityError` on `save()`, `ValidationError` is also
> raised during model validation when the `UniqueConstraint` is violated.

## `CheckConstraint`

#### `class CheckConstraint(* (Separador de parâmetros somente-nomeados (PEP 3102)), check, name)`

Creates a check constraint in the database.

### `check`

#### `CheckConstraint.check`

A [`Q`](/pt-br/3.0/ref/models/querysets/#django.db.models.Q) object that specifies the check you want the constraint to
enforce.

For example, `CheckConstraint(check=Q(age__gte=18), name='age_gte_18')`
ensures the age field is never less than 18.

### `name`

#### `CheckConstraint.name`

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

> **Changed in Django 3.0**
>
> Interpolation of  `'%(app_label)s'` and `'%(class)s'` was added.

## `UniqueConstraint`

#### `class UniqueConstraint(* (Separador de parâmetros somente-nomeados (PEP 3102)), fields, name, condition=None)`

Creates a unique constraint in the database.

### `fields`

#### `UniqueConstraint.fields`

A list of field names that specifies the unique set of columns you want the
constraint to enforce.

For example, `UniqueConstraint(fields=['room', 'date'],
name='unique_booking')` ensures each room can only be booked once for each
date.

### `name`

#### `UniqueConstraint.name`

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

> **Changed in Django 3.0**
>
> Interpolation of  `'%(app_label)s'` and `'%(class)s'` was added.

### `condition`

#### `UniqueConstraint.condition`

A [`Q`](/pt-br/3.0/ref/models/querysets/#django.db.models.Q) object that specifies the condition you want the constraint to
enforce.

Por exemplo:

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

ensures that each user only has one draft.

These conditions have the same database restrictions as
[`Index.condition`](/pt-br/3.0/ref/models/indexes/#django.db.models.Index.condition).