#30631: Prefixing Q Objects
-------------------------------------+-------------------------------------
Reporter: efficiosoft | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 2.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: prefix q objects | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by efficiosoft):
* needs_docs: 0 => 1
* needs_tests: 0 => 1
Old description:
> I'm currently spending a lot of time on development of a project using
> Django and worked out something that I think could be of use for all
> Django users.
>
> I added a new `.prefix(prefix)` method to the `Q` object, allowing to
> shift pre-built `q` objects to a related field. I think this can change
> the way people build managers completely, because instead of methods
> returning filtered querysets, one can just return `Q` objects, which can
> then be used from related models without repeating the filtering logic.
>
> This is the simple implementation.
>
> ```
> class Q(django.db.models.Q):
> """
> A custom Q implementation that allows prefixing existing Q objects
> with some
> related field name dynamically.
> """
>
> def prefix(self, prefix):
> """Recursively copies the Q object, prefixing all lookup keys.
>
> The prefix and the existing filter key are delimited by the
> lookup separator __.
> Use this feature to delegate existing query constraints to a
> related field.
> """
> return type(self)(
> *(
> child.prefix(prefix)
> if isinstance(child, Q)
> else (prefix + LOOKUP_SEP + child[0], child[1])
> for child in self.children
> ),
> _connector=self.connector,
> _negated=self.negated,
> )
> ```
>
> What do you think, is it worth creating a PR for this functionality? I
> haven't written the docs yet, but could write something if you like the
> addition.
>
> Best regards
> Robert
New description:
I'm currently spending a lot of time on development of a project using
Django and worked out something that I think could be of use for all
Django users.
I added a new `.prefix(prefix)` method to the `Q` object, allowing to
shift pre-built `q` objects to a related field. I think this can change
the way people build managers completely, because instead of methods
returning filtered querysets, one can just return `Q` objects, which can
then be used from related models without repeating the filtering logic.
This is the simple implementation.
{{{
class Q(django.db.models.Q):
"""
A custom Q implementation that allows prefixing existing Q objects
with some
related field name dynamically.
"""
def prefix(self, prefix):
"""Recursively copies the Q object, prefixing all lookup keys.
The prefix and the existing filter key are delimited by the lookup
separator __.
Use this feature to delegate existing query constraints to a
related field.
"""
return type(self)(
*(
child.prefix(prefix)
if isinstance(child, Q)
else (prefix + LOOKUP_SEP + child[0], child[1])
for child in self.children
),
_connector=self.connector,
_negated=self.negated,
)
}}}
What do you think, is it worth creating a PR for this functionality? I
haven't written the docs yet, but could write something if you like the
addition.
Best regards
Robert
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30631#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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.a64aaf57e45796e8c71de26a7f998510%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
