#32548: Support passing conditional expressions to Q().
-------------------------------------+-------------------------------------
Reporter: jonathan-golorry | Owner: jonathan-
Type: | golorry
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: Q objects, | Triage Stage: Accepted
deconstruct |
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jonathan-golorry):
Django already passes conditional expressions to Q objects internally.
https://github.com/django/django/blob/main/django/db/models/expressions.py#L113
Tested here
https://github.com/django/django/blob/main/tests/expressions/tests.py#L827
That test is only succeeding because `Q(...) | Q(Q())` is treated
differently from `Q(...) | Q()`.
As for the form of `.deconstruct()`, is there any reason for keeping the
special case? It's:
1. Inconsistent: `Q(x=1).deconstruct()` vs `Q(x=1, y=2).deconstruct()`
2. Fragile: Unsupported inputs like `Q(False)` sometimes (but not always!)
lead to "not subscriptable" errors.
3. Incorrect: `Q(("x", 1)).deconstruct()` incorrectly puts the condition
in kwargs instead of args.
--
Ticket URL: <https://code.djangoproject.com/ticket/32548#comment:4>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/074.a56d84f208baaab6154bd3a07b92214a%40djangoproject.com.
