#35676: ExclusionConstraint that includes a ForeignKey fails validation in
ModelForm
------------------------------+------------------------------------
Reporter: Take Weiland | Owner: (none)
Type: Bug | Status: new
Component: Forms | Version: 5.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
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:
> The only potential issue might be that when creating new objects then
the foreign key field will still be None, because the related object isn't
saved to the DB yet.
That's another can of worm and an issue that is unfortunately pretty hard
to solve. The way this is emulated in today for unique constraints
validation in admin inlines can be found in `ModelFormSet.validate_unique`
[https://github.com/django/django/blob/b99c608ea10cabc97a6b251cdb6e81ef2a83bdcf/django/forms/models.py#L803-L860
source].
The gist of it is that
[https://github.com/django/django/blob/b99c608ea10cabc97a6b251cdb6e81ef2a83bdcf/django/forms/models.py#L803-L860
for each fields marked to be unique within the formset] all associated
values are combined and
[https://github.com/django/django/blob/b99c608ea10cabc97a6b251cdb6e81ef2a83bdcf/django/forms/models.py#L830
the name of the field is used to make duplicate values collide]. This is
poorly implemented IMO as it doesn't account for database level uniqueness
(e.g. if a field has a specific `db_collation` that is case insensitive
then `"foo" == "Foo"` and only a transit through the database can
determine that)
If you wanted to manually implement a similar emulation for exclusion
constraints you could define a `BaseInlineFormSet` subclass and override
its `clean` method to iterate through all forms and ensure that each form
contains non-overlapping `date_range` in Python. This subclass could then
be assigned to `BlockedDaysRangeInline.formset`.
What I'm curious to hear about is whether the patch above prevents the
problematic SQL query from being executed in the first place.
--
Ticket URL: <https://code.djangoproject.com/ticket/35676#comment:3>
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/010701914e16b8ba-4981cf36-e120-47c1-a395-5b59b11727f1-000000%40eu-central-1.amazonses.com.
