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 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:
>
>
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
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 field to
determine if the instance was marked as deleted.
