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,
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 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
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 have been
