#34293: Extra validation introduced in 30581 breaks certain constraint setups
-------------------------------------+-------------------------------------
Reporter: Ionel Cristian | Owner: nobody
Mărieș |
Type: Bug | Status: new
Component: Database layer | Version: 4.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
I think I understand what's going on here.
The reported defined constraints in a way makes assumption that
`schedule_start_lt_end` will always be enforced before
`schedule_exclude_overlapping` is which depends on the order of creation
of constraints on the table and the order of the members of
`Meta.constraints`.
I think this might be an argument to make `Model.validate_constraint`
abort on the first `ValidationError` it encounters. The alternative
solution would be document that ''dependent'' constraints should use
`conditions` so they can be skipped on invalid input.
For example, in this case `schedule_exclude_overlapping` should be defined
in the following manner since it uses the `timetstzrange` function which
expects that ''range lower bound must be less than or equal to range upper
bound'' as pointed out in the (un)helpful message.
{{{#!python
constraints.ExclusionConstraint(
name='schedule_exclude_overlapping',
expressions=[
(
TimeTsTzRange(
'start_time',
'end_time',
fields.RangeBoundary(inclusive_upper=True),
),
fields.RangeOperators.OVERLAPS,
),
('weekday', fields.RangeOperators.EQUAL),
('therapist', fields.RangeOperators.EQUAL),
],
condition=(
Q(start_time__lt=F('end_time')) |
Q(start_time__lte=HALF_HOUR_BEFORE_MIDNIGHT, end_time=MIDNIGHT)
)
)
}}}
I would argue that this is more of a user error since
[https://www.postgresql.org/docs/15/ddl-constraints.html PostgreSQL
doesn't offer guarantees about the order in which it will run constraints]
> The order doesn't matter. It does not necessarily determine in which
order the constraints are checked.
which means that depending on the order in which PostgreSQL choose to
check constraints the user could either get an `IntegrityError` or a
`DataError` depending which attempting to insert data that violates one
constraint and provides invalid data for the other.
--
Ticket URL: <https://code.djangoproject.com/ticket/34293#comment:5>
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/01070185ebdc6288-d45f3e0c-38c9-45a1-b759-e5004f10bb3a-000000%40eu-central-1.amazonses.com.
