Справочник по ограничениям

Классы, определённые в этом модуле, создают ограничения в базе данных. Они добавляются в параметр модели Meta.constraints.

Обращение к встроенным ограничениям

Ограничения определены в django.db.models.constraints, но для удобства они импортированы в django.db.models. Стандартная конвенция — использовать from django.db import models и ссылаться на ограничения как на models.<Foo>Constraint.

Ограничения в абстрактных базовых классах

Вы всегда должны указывать уникальное имя для ограничения. Таким образом, вы обычно не можете указать ограничение в абстрактном базовом классе, так как параметр Meta.constraints наследуется подклассами, с точно такими же значениями атрибутов (включая name) каждый раз. Чтобы обойти конфликты имён, часть имени может содержать '%(app_label)s' и '%(class)s', которые заменяются, соответственно, нижним регистром метки приложения и имени класса конкретной модели. Например, CheckConstraint(check=Q(age__gte=18), name='%(app_label)s_%(class)s_is_adult').

Валидация ограничений

В общем случае, ограничения не проверяются во время full_clean(), и не вызывают ValidationError. Вместо этого, вы получите ошибку целостности базы данных при save(). UniqueConstraint без condition (т.е. нечастичные уникальные ограничения) и expressions (т.е. нефункциональные уникальные ограничения) отличаются в этом отношении, так как они используют существующую логику validate_unique() и, следовательно, позволяют двухэтапную валидацию. В дополнение к IntegrityError при save(), ValidationError также возникает во время валидации модели, когда нарушается UniqueConstraint.

`CheckConstraint`

class CheckConstraint(*, check, name): Создаёт ограничение проверки в базе данных.

`check`

CheckConstraint.check

Объект Q или булевое Expression, который определяет проверку, которую должно обеспечить ограничение.

Например, CheckConstraint(check=Q(age__gte=18), name='age_gte_18') гарантирует, что поле age никогда не будет меньше 18.

`name`

CheckConstraint.name

Имя ограничения. Вы всегда должны указать уникальное имя для ограничения.

`UniqueConstraint`

class UniqueConstraint(*expressions, fields=(), name=None, condition=None, deferrable=None, include=None, opclasses=()): Создаёт уникальное ограничение в базе данных.

`expressions`

UniqueConstraint.expressions

Новое в Django 4.0.

Позиционный аргумент *expressions позволяет создавать функциональные уникальные ограничения на выражения и функции базы данных.

Например:

UniqueConstraint(Lower('name').desc(), 'category', name='unique_lower_name_category')

создаёт уникальное ограничение на значение поля name в порядке убывания и поле category в стандартном порядке возрастания.

Функциональные уникальные ограничения имеют те же ограничения базы данных, что и Index.expressions.

`fields`

UniqueConstraint.fields

Список имён полей, который определяет уникальный набор столбцов, которые вы хотите применить к ограничению.

Например, UniqueConstraint(fields=['room', 'date'], name='unique_booking') гарантирует, что каждый номер комнаты может быть забронирован только один раз для каждой даты.

`name`

UniqueConstraint.name

Имя ограничения. Вы всегда должны указать уникальное имя для ограничения.

`condition`

UniqueConstraint.condition

Объект Q, который определяет условие, которое должно выполнить ограничение.

Например:

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

гарантирует, что каждый пользователь имеет только один черновик.

Эти условия имеют те же ограничения базы данных, что и Index.condition.

`deferrable`

UniqueConstraint.deferrable

Установите этот параметр для создания откладываемого уникального ограничения. Допустимые значения — Deferrable.DEFERRED или Deferrable.IMMEDIATE. Например:

from django.db.models import Deferrable, UniqueConstraint

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

По умолчанию ограничения не откладываются. Отложенное ограничение не будет проверяться до конца транзакции. Немедленное ограничение будет проверяться сразу после каждой команды.

MySQL, MariaDB и SQLite

Откладываемые уникальные ограничения игнорируются в MySQL, MariaDB и SQLite, так как ни одно из них их не поддерживает.

Предупреждение

Отложенные уникальные ограничения могут привести к потере производительности.

`include`

UniqueConstraint.include

Новое в Django 3.2.

Список или кортеж имён полей, которые нужно включить в охватывающий уникальный индекс в качестве столбцов, не являющихся ключами. Это позволяет использовать индексные сканирования для запросов, которые выбирают только поля, включенные в include, и фильтруют только по уникальным полям fields.

Например:

UniqueConstraint(name='unique_booking', fields=['room', 'date'], include=['full_name'])

позволит фильтровать по room и date, а также выбирать full_name, получая данные только из индекса.

include поддерживается только в PostgreSQL.

Столбцы, не являющиеся ключами, имеют те же ограничения базы данных, что и Index.include.

`opclasses`

UniqueConstraint.opclasses

Новое в Django 3.2.

Имена классов операторов PostgreSQL для использования в этом уникальном индексе. Если вам требуется пользовательский класс оператора, вы должны предоставить его для каждого поля в индексе.

Например:

UniqueConstraint(name='unique_username', fields=['username'], opclasses=['varchar_pattern_ops'])

создаёт уникальный индекс на username с использованием varchar_pattern_ops.

opclasses игнорируются для баз данных помимо PostgreSQL.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/4.0/ref/models/constraints/