#30581: Allow constraints to be used for validation (in Python)
-------------------------------------+-------------------------------------
Reporter: Carlton Gibson | Owner: Sanskar
| Jaiswal
Type: New feature | Status: assigned
Component: Database layer | Version: 2.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: constraints, | Triage Stage: Accepted
validation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* cc: Simon Charette (added)
Comment:
I suggest you have a look at
[https://github.com/django/django/blob/5dabb6002ed773c150da4bd3aee756df75d218c2/django/db/models/base.py#L997-L1144
the existing] `Model.validate_unique` logic and draft an API that would
allow users to define their own constraints with custom validation.
The interface should be flexible enough to implement concepts such as
`unique_for_date`
([https://docs.djangoproject.com/en/3.0/ref/models/fields/#unique-for-date
and friends]) and
[https://docs.djangoproject.com/en/3.0/ref/contrib/postgres/constraints/#exclusionconstraint
exclusion constraints] in a way that is similar to how `Field.unique=True`
and `Model._meta.unique_together` are handled right now.
I believe that we should aim for a setup where all of the current
''unique'' validation logic is deferred to `UniqueConstraint` by making
`Field.unique=True` and `unique_together` result in
`UniqueConstraint.auto_created = True` entries in
`Model._meta.constraints`. These `auto_created` constraints entries would
be ignored by migrations, just like `ManyToManyField` auto-created
intermediary models are, and should prove that the constraint enforcing
mechanism is flexible enough to cover all of the current use cases
`validate_unique` currently has.
I order to achieve that we'll likely want to define a new
`Constraint.enforce` (or `validate`) method that accepts an optional
existing model instance and a set of excluded fields that would raise on
violation. It would then be the responsibility of the subclass to
implement or not this function (e.g. we could skip it on
`UniqueConstraint` with a `condition` at first as they are more complex to
implement).
I hope this gives you a better idea of a plan to tackle this issue. Happy
to move the discussion to the mailing list to gather more feedback if
deemed more appropriate, that's just the way I envisioned it.
--
Ticket URL: <https://code.djangoproject.com/ticket/30581#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.6ec448f5d9ea79dae0058c528572536e%40djangoproject.com.
