#36518: full_clean crashes on model with both a CheckConstraint and a
GeneratedField with a Case expression
-------------------------------------+-------------------------------------
Reporter: Olivier Dalang | Owner: Simon
| Charette
Type: Bug | Status: assigned
Component: Database layer | Version: 5.2
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
Thanks for the ping and test Sarah, here's my analysis of the situation.
We've known that validation of constraints including unresolved lookups
(`Q`, `Case`) is since broken since 4.2 (#34871).
By fixing #35575 and requiring that `GeneratedField` expressions are
replaced with the validated against instance values we triggered the same
problem for `GeneratedField` making use of unresolved lookups hence why
the patch for #34871 happens to resolve this issue.
The interesting part is that since we have constraint asks for all fields
replacements via `_get_field_expression_map` (except for the ones part of
`excludes`) even if only a few ones are required by the constraint itself
the problem can now be triggered even if a generated field making use of
unresolved lookup is not referenced by the constraint. For example, in the
reported case the `age_valid` constraint doesn't refer to the
`is_old_enough` field.
Looking back at [https://github.com/django/django/pull/19190/ the proposed
patch] it seems like it would be adequate to address this issue even if it
duplicates `sql.Query.build_filter` logic as we likely want to avoid also
backporting a refactor. It would keep the unnecessary work in performed by
`_get_field_expression_map` though.
The only alternative I see is likely more invasive as it would require us
to flip the logic around by having constraint introspect their respective
expressions (e.g. `condition`, `constraint`) and only request that fields
of interests are considered by `_get_field_expression_map`. This seems
like a worthy optimization that would address this issue but it wouldn't
address the underlying cause of #34871 and is likely risky as a backport.
--
Ticket URL: <https://code.djangoproject.com/ticket/36518#comment:6>
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 visit
https://groups.google.com/d/msgid/django-updates/010701985dac8512-af01878e-3891-4888-bcb5-988cccc41ab5-000000%40eu-central-1.amazonses.com.
