I completely agree with Gary's argumentation here. And I would love to see
.limit() introduced (or array slicing adapted).
I ran into a situation where I have access into intermediate queryset()
construction, where I normally do add .filter() statements, but now I had
to limit a number of queries returned and it caused an exception, because
some other code further down the stack was modifying.
The actual query construction should be the final step, and in that case it
doesn't matter when and how many times an equivalent of .limit() (or for
that matter slicing) was called on the queryset. Just use the final one.
On Wednesday, December 5, 2007 5:14:55 AM UTC, Gary Wilson wrote:
>
> Luke Plant wrote:
> > On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
> >
> >> Sort of my point. Since filter() and [:] both return QuerySets why
> >> should they be any different:
> >>
> >> UTPerson.objects.all().filter(name__startswith='a')[:10]
> >
> > 1) This, logically, should return the first ten people whose 'name'
> > starts with 'a'.
> >
> >> UTPerson.objects.all()[:10].filter(name__startswith='a')
> >
> > 2) This should return the people whose 'name' starts with 'a' from the
> > first 10 rows in the table
> >
> > This is almost certainly what most people would expect (I guess we could
> > argue about that...) But there is no way to specify it in SQL without
> > doing subselects -- you will end up doing 1) instead.
>
> Does that mean that most people also expect:
>
>
> UTPerson.objects.filter(first_name__startswith='a').filter(last_name__startswith='b')
>
> to return the people whose last name starts with 'b' from the people whose
> first name starts with 'a'? Maybe, but filter doesn't work that way just
> like
> slicing wouldn't work that way.
>
> I should be able to keep piling things onto the QuerySet. You can do it
> with
> all the other QuerySet methods that return QuerySets. Why not with the
> slicing syntax (which returns a QuerySet object)?
>
> I am just trying to spark some discussion on the matter. Personally, I
> wouldn't mind if slices were changed to always return lists (like the do
> currently if you use a step). And then we and in a limit() method for
> people
> who want QuerySets returned so that they can be built up and lazily
> evaluated.
>
> I see:
>
> UTPerson.objects.all().limit(10).filter(...).limit(10)
>
> acting like order_by() in that the second limit would override the first.
>
> > Remember that there are other methods that do not or cannot commute e.g.
> > trying to do order_by() after slicing -- it would change the objects
> > that are returned. Just because some methods do happen to commute
> > (filtering) doesn't mean that others should.
>
> Well, with order_by() you can do:
>
>
> UTPerson.objects.all().order_by('first_name').filter(...).order_by('last_name')
>
> In this case, the second order_by() overrides the first.
>
> Gary
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/be64f70b-4443-4c76-9ff5-db3f35fdef14%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
