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 engine implementations. If database
engines were ideal, equivalent queries would have equivalent
performance.
I'm no database expert and you are probably right. At least that was
what I often heard, but I didn't take any benchmarks myself.
More generally: The idea does seem interesting, but note that the
prefix() method doesn't need to be a member of the Q class -- it seems
to be just as easy to write an external function to do the same thing:
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, imho. Not to say that it must be
in Django directly.
So, this can be added as a utility function to your project, or even
published in a package on PyPI, without being in Django.
That's the way I planned to do it. When I like the API, I'm going to add
unittests and publish the package, the structure is already there in the
repo.
Given this, the question is no longer just "is this useful", but rather
"does this promote use-patterns we wish to encourage". On the ticket,
Mariusz gave an example of a possible use-case we'd actually want to
discourage. Here on the list, better use-cases were shown.
>
One use case you didn't bring up is using a Q object with prefix as a
"template" -- consider querying for the "first Tuesday of the month";
if there's a date field `d`, it would need to be something like
...filter(d__week_day=3, d__day__lte=7)
But with a prefix, we could say something like
def is_first_tuesday(field)
return Q(week_day=3, day__lte=7).prefix(field)
and then use it in
... filter(is_first_tuesday('d'),...)
Which, at a very first glance, looks like an excellent use-case. Except
that Django already has a way to support this, using custom lookups,
which blend better into the QuerySet API -- and so, have technical
advantages beyond the fact that they already exist and "There should be
one obvious way to do it".
Looks interesting, haven't thought of such a use case myself yet.
So, I, at least, remain unconvinced that overall, this is an
improvement to Django's API.
I agree that this makes most sense in conjunction with the additional
QProvider class for defining hybrid Q and QuerySet generators on
managers, which, even though very short and simple, is another addition
to be considered in this regard.
Thanks for taking the time.
Best regards
Robert
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/707036ac-987f-7cb1-1629-882e24d694c7%40efficiosoft.com.
For more options, visit https://groups.google.com/d/optout.
