Am 11.07.19 um 19:20 schrieb Robert Schindler:
Sure it is, but I, personally, find it more appealing to have the
functionality as part of the Q object itself, because it operates on a
single Q object as input and returns another one, which makes this an
ideal candidate for an object member, imh
Hi Shai,
Am 11.07.19 um 18:57 schrieb Shai Berger:
Not so clearly. Querysets are lazy, so the above actually only performs
one database roundtrip, and whether a join is more or less performant
than an equivalent query-with-a-sub-query can depend on many details --
mostly details of the database
Hi Robert,
On Wed, 10 Jul 2019 12:13:08 -0700 (PDT)
Robert Schindler wrote:
> The traditional approach would be to implement methods for filtering
> the queryset on both the managers for Subscription and User and thus
> duplicating logic, or use sub-queries like so:
>
> User.objects.filter(subs
Hi again,
Am 11.07.19 um 09:54 schrieb Robert Schindler:
> For convenience, I created this module [0], which makes declaring the
> query logic as part of a model's manager really straightforward and also
> provides the well-known API for getting filtered querysets (aka
> Fruit.objects.green()).
Hi Matthew,
Am 11.07.19 um 04:13 schrieb Matthew Pava:
I had a use for such a feature, though I used an implementation more
specific to my application.
Basically, I have a model and then I have several other models that are
directly related to that model. So in the base model I would have a
one field on one model in my project.
From: 'Robert Schindler' via Django developers (Contributions to Django itself)
[mailto:django-developers@googlegroups.com]
Sent: Wednesday, July 10, 2019 2:13 PM
To: Django developers (Contributions to Django itself)
Subject: Prefixing Q Objec
Hi all,
I've been redirected to the mailing list from the ticked I opened [0].
Therein, I proposed to add a new method to the Q object API for prefixing Q
objects with a related field's name in order to be able to create reusable
Q objects.
I think the use case I pointed out might
