#22885: Make Query.set_limits a setter
-------------------------------------+-------------------------------------
Reporter: jorgecarleitao | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: master
Component: Database layer | Resolution: wontfix
(models, ORM) | Triage Stage:
Severity: Normal | Unreviewed
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by russellm):
* status: new => closed
* needs_better_patch: => 0
* resolution: => wontfix
* needs_tests: => 0
* needs_docs: => 0
Comment:
It's worth pointing out that the referenced thread is from 2007 - when the
internals of QuerySet were being massively refactored - and then revived
for some reason in 2013. The discussion comes from a time where we were
sorting out the basic semantics of the QuerySet API. That API is now
stable, well established, and has a firm set of community expectations.
Slicing is a terminal operation for a reason - there's no other reasonable
way to interpret it otherwise. Consider the following query:
{{{
Author.objects.filter(name_startswith='a')[:10].filter(name__contains='e')
}}}
That requires you to find the first 10 authors whose name starts with a,
and then filter that list of 10 down to only those that have an 'e' in
their name as well. It's a completely different query to:
{{{
Author.objects.filter(name_startswith='a').filter(name__contains='e')[:10]
}}}
which finds the first 10 authors that start with an 'a' *and* have an e in
their name.
It's *possible* to issue the former query in SQL, but it certainly isn't
simple - it requires a join, even though you're only dealing with one
table.
Alternatively, you'd need to come up with an interpretation of
`set_limit()` that is inconsistent with all the other operations you can
perform on a query set.
If there was a pressing use case for this particular construct, I might be
inclined to explore the options further, but the ticket doesn't provide
any example of *why* this construct is needed. Closing wontfix; if you
want to make the case for this feature, please start a discussion on
django-dev.
--
Ticket URL: <https://code.djangoproject.com/ticket/22885#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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/072.73b8a85f99a2ea393c20f27716ed5b84%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
