constraints.txt 8.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269
  1. =====================
  2. Constraints reference
  3. =====================
  4. .. module:: django.db.models.constraints
  5. .. currentmodule:: django.db.models
  6. The classes defined in this module create database constraints. They are added
  7. in the model :attr:`Meta.constraints <django.db.models.Options.constraints>`
  8. option.
  9. .. admonition:: Referencing built-in constraints
  10. Constraints are defined in ``django.db.models.constraints``, but for
  11. convenience they're imported into :mod:`django.db.models`. The standard
  12. convention is to use ``from django.db import models`` and refer to the
  13. constraints as ``models.<Foo>Constraint``.
  14. .. admonition:: Constraints in abstract base classes
  15. You must always specify a unique name for the constraint. As such, you
  16. cannot normally specify a constraint on an abstract base class, since the
  17. :attr:`Meta.constraints <django.db.models.Options.constraints>` option is
  18. inherited by subclasses, with exactly the same values for the attributes
  19. (including ``name``) each time. To work around name collisions, part of the
  20. name may contain ``'%(app_label)s'`` and ``'%(class)s'``, which are
  21. replaced, respectively, by the lowercased app label and class name of the
  22. concrete model. For example ``CheckConstraint(check=Q(age__gte=18),
  23. name='%(app_label)s_%(class)s_is_adult')``.
  24. .. admonition:: Validation of Constraints
  25. Constraints are checked during the :ref:`model validation
  26. <validating-objects>`.
  27. .. admonition:: Validation of Constraints with ``JSONField``
  28. Constraints containing :class:`~django.db.models.JSONField` may not raise
  29. validation errors as key, index, and path transforms have many
  30. database-specific caveats. This :ticket:`may be fully supported later
  31. <34059>`.
  32. You should always check that there are no log messages, in the
  33. ``django.db.models`` logger, like *"Got a database error calling check() on
  34. …"* to confirm it's validated properly.
  35. .. versionchanged:: 4.1
  36. In older versions, constraints were not checked during model validation.
  37. ``BaseConstraint``
  38. ==================
  39. .. class:: BaseConstraint(name, violation_error_message=None)
  40. Base class for all constraints. Subclasses must implement
  41. ``constraint_sql()``, ``create_sql()``, ``remove_sql()`` and
  42. ``validate()`` methods.
  43. All constraints have the following parameters in common:
  44. ``name``
  45. --------
  46. .. attribute:: BaseConstraint.name
  47. The name of the constraint. You must always specify a unique name for the
  48. constraint.
  49. ``violation_error_message``
  50. ---------------------------
  51. .. versionadded:: 4.1
  52. .. attribute:: BaseConstraint.violation_error_message
  53. The error message used when ``ValidationError`` is raised during
  54. :ref:`model validation <validating-objects>`. Defaults to
  55. ``"Constraint “%(name)s” is violated."``.
  56. ``validate()``
  57. --------------
  58. .. versionadded:: 4.1
  59. .. method:: BaseConstraint.validate(model, instance, exclude=None, using=DEFAULT_DB_ALIAS)
  60. Validates that the constraint, defined on ``model``, is respected on the
  61. ``instance``. This will do a query on the database to ensure that the
  62. constraint is respected. If fields in the ``exclude`` list are needed to
  63. validate the constraint, the constraint is ignored.
  64. Raise a ``ValidationError`` if the constraint is violated.
  65. This method must be implemented by a subclass.
  66. ``CheckConstraint``
  67. ===================
  68. .. class:: CheckConstraint(*, check, name, violation_error_message=None)
  69. Creates a check constraint in the database.
  70. ``check``
  71. ---------
  72. .. attribute:: CheckConstraint.check
  73. A :class:`Q` object or boolean :class:`~django.db.models.Expression` that
  74. specifies the check you want the constraint to enforce.
  75. For example, ``CheckConstraint(check=Q(age__gte=18), name='age_gte_18')``
  76. ensures the age field is never less than 18.
  77. .. admonition:: Oracle
  78. Checks with nullable fields on Oracle must include a condition allowing for
  79. ``NULL`` values in order for :meth:`validate() <BaseConstraint.validate>`
  80. to behave the same as check constraints validation. For example, if ``age``
  81. is a nullable field::
  82. CheckConstraint(check=Q(age__gte=18) | Q(age__isnull=True), name='age_gte_18')
  83. .. versionchanged:: 4.1
  84. The ``violation_error_message`` argument was added.
  85. ``UniqueConstraint``
  86. ====================
  87. .. class:: UniqueConstraint(*expressions, fields=(), name=None, condition=None, deferrable=None, include=None, opclasses=(), violation_error_message=None)
  88. Creates a unique constraint in the database.
  89. ``expressions``
  90. ---------------
  91. .. attribute:: UniqueConstraint.expressions
  92. Positional argument ``*expressions`` allows creating functional unique
  93. constraints on expressions and database functions.
  94. For example::
  95. UniqueConstraint(Lower('name').desc(), 'category', name='unique_lower_name_category')
  96. creates a unique constraint on the lowercased value of the ``name`` field in
  97. descending order and the ``category`` field in the default ascending order.
  98. Functional unique constraints have the same database restrictions as
  99. :attr:`Index.expressions`.
  100. ``fields``
  101. ----------
  102. .. attribute:: UniqueConstraint.fields
  103. A list of field names that specifies the unique set of columns you want the
  104. constraint to enforce.
  105. For example, ``UniqueConstraint(fields=['room', 'date'],
  106. name='unique_booking')`` ensures each room can only be booked once for each
  107. date.
  108. ``condition``
  109. -------------
  110. .. attribute:: UniqueConstraint.condition
  111. A :class:`Q` object that specifies the condition you want the constraint to
  112. enforce.
  113. For example::
  114. UniqueConstraint(fields=['user'], condition=Q(status='DRAFT'), name='unique_draft_user')
  115. ensures that each user only has one draft.
  116. These conditions have the same database restrictions as
  117. :attr:`Index.condition`.
  118. ``deferrable``
  119. --------------
  120. .. attribute:: UniqueConstraint.deferrable
  121. Set this parameter to create a deferrable unique constraint. Accepted values
  122. are ``Deferrable.DEFERRED`` or ``Deferrable.IMMEDIATE``. For example::
  123. from django.db.models import Deferrable, UniqueConstraint
  124. UniqueConstraint(
  125. name='unique_order',
  126. fields=['order'],
  127. deferrable=Deferrable.DEFERRED,
  128. )
  129. By default constraints are not deferred. A deferred constraint will not be
  130. enforced until the end of the transaction. An immediate constraint will be
  131. enforced immediately after every command.
  132. .. admonition:: MySQL, MariaDB, and SQLite.
  133. Deferrable unique constraints are ignored on MySQL, MariaDB, and SQLite as
  134. neither supports them.
  135. .. warning::
  136. Deferred unique constraints may lead to a `performance penalty
  137. <https://www.postgresql.org/docs/current/sql-createtable.html#id-1.9.3.85.9.4>`_.
  138. ``include``
  139. -----------
  140. .. attribute:: UniqueConstraint.include
  141. A list or tuple of the names of the fields to be included in the covering
  142. unique index as non-key columns. This allows index-only scans to be used for
  143. queries that select only included fields (:attr:`~UniqueConstraint.include`)
  144. and filter only by unique fields (:attr:`~UniqueConstraint.fields`).
  145. For example::
  146. UniqueConstraint(name='unique_booking', fields=['room', 'date'], include=['full_name'])
  147. will allow filtering on ``room`` and ``date``, also selecting ``full_name``,
  148. while fetching data only from the index.
  149. ``include`` is supported only on PostgreSQL.
  150. Non-key columns have the same database restrictions as :attr:`Index.include`.
  151. ``opclasses``
  152. -------------
  153. .. attribute:: UniqueConstraint.opclasses
  154. The names of the `PostgreSQL operator classes
  155. <https://www.postgresql.org/docs/current/indexes-opclass.html>`_ to use for
  156. this unique index. If you require a custom operator class, you must provide one
  157. for each field in the index.
  158. For example::
  159. UniqueConstraint(name='unique_username', fields=['username'], opclasses=['varchar_pattern_ops'])
  160. creates a unique index on ``username`` using ``varchar_pattern_ops``.
  161. ``opclasses`` are ignored for databases besides PostgreSQL.
  162. ``violation_error_message``
  163. ---------------------------
  164. .. versionadded:: 4.1
  165. .. attribute:: UniqueConstraint.violation_error_message
  166. The error message used when ``ValidationError`` is raised during
  167. :ref:`model validation <validating-objects>`. Defaults to
  168. :attr:`.BaseConstraint.violation_error_message`.
  169. This message is *not used* for :class:`UniqueConstraint`\s with
  170. :attr:`~UniqueConstraint.fields` and without a
  171. :attr:`~UniqueConstraint.condition`. Such :class:`~UniqueConstraint`\s show the
  172. same message as constraints defined with
  173. :attr:`.Field.unique` or in
  174. :attr:`Meta.unique_together <django.db.models.Options.constraints>`.