1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
=====================
Constraints reference
=====================
.. module:: django.db.models.constraints
.. currentmodule:: django.db.models
.. versionadded:: 2.2
The classes defined in this module create database constraints. They are added
in the model :attr:`Meta.constraints <django.db.models.Options.constraints>`
option.
.. admonition:: Referencing built-in constraints
Constraints are defined in ``django.db.models.constraints``, but for
convenience they're imported into :mod:`django.db.models`. The standard
convention is to use ``from django.db import models`` and refer to the
constraints as ``models.<Foo>Constraint``.
.. admonition:: 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
:attr:`Meta.constraints <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')``.
.. admonition:: 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
:attr:`~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(*, check, name)
Creates a check constraint in the database.
``check``
---------
.. attribute:: CheckConstraint.check
A :class:`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``
--------
.. attribute:: CheckConstraint.name
The name of the constraint.
.. versionchanged:: 3.0
Interpolation of ``'%(app_label)s'`` and ``'%(class)s'`` was added.
``UniqueConstraint``
====================
.. class:: UniqueConstraint(*, fields, name, condition=None)
Creates a unique constraint in the database.
``fields``
----------
.. attribute:: 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``
--------
.. attribute:: UniqueConstraint.name
The name of the constraint.
.. versionchanged:: 3.0
Interpolation of ``'%(app_label)s'`` and ``'%(class)s'`` was added.
``condition``
-------------
.. attribute:: UniqueConstraint.condition
A :class:`Q` object that specifies the condition you want the constraint to
enforce.
For example::
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
:attr:`Index.condition`.
|
