#32946: Prefer non-kwargs construction of dynamically generated Q objects
-------------------------------------+-------------------------------------
Reporter: Keryn Knight | Owner: Keryn
Type: | Knight
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
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 Mariusz Felisiak):
* stage: Unreviewed => Accepted
Comment:
Agreed.
> I also think that `Q(a=1, b=2, _connector=Q.OR)` and/or the
`reduce(...)` should be documented in the
https://docs.djangoproject.com/en/3.2/topics/db/queries/#complex-lookups-
with-q section. Dynamic Q construction is fairly common IME, doesn't
appear to be covered there, and ultimately points to Q test cases which
''also'' don't show any form of dynamic variants.
Using `Q(a=1, b=2, _connector=...)` internally is fine, but I don't think
we would like to encourage users to use it. I'd add an example with
`reduce()` which was mentioned in several tickets.
--
Ticket URL: <https://code.djangoproject.com/ticket/32946#comment:1>
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/067.edfe10edc55c2c7b27c312857d3923a4%40djangoproject.com.
