On Tue, 2008-04-15 at 19:33 -0700, Travis Parker wrote:
> > Because every time you modify a QuerySet you are changing the results
> > that will be returned. Calling filter() will restrict the results.
> > Calling order_by() will change the order the results are returned in.
> > And so on. Thus, the cache of the queyrset that was cloned is invalid
> > for the new queryset.
>
> But in most of the queryset-returning methods, the changes to the
> results don't result in any data that wasn't already there, just a
> subset or reordering of already-fetched results.
Not true. Suppose I add order_by('name') to a queryset. Does it hit the
database again or not? You can't tell without doing a bunch of
introspection, because 'name' could be a foreign key to a model with its
own default ordering. There are lots of other exception cases, too. All
that additional processing has to be done every single time in what is
already a fairly costly execution path.
I suspect it will also be fairly tricky to make this robust for all
Queryset subclasses, since it makes assumptions about the types of
objcets in the cache.
> > If you already have the results in the cache and you know that your
> > modifications to the queryset could just as easily be done in Python,
> > then just do them in Python yourself.
>
> That's what I've done this time - next time it would be nice if django
> did it for me. I shouldn't have to go outside of django's ORM just to
> avoid unnecessary database traffic.
Come up with a patch that implements this change and let's see how
complex it is and what the performance impact is. My guess is that it's
not worth it, since you can already do this in the relatively few cases
when it's applicable, but code it up and so we can see what it looks
like.
I think you'll find that typically querysets are created incrementally
but only accessed once, not
created-accessed-modified-accessed-modified-accessed and when you do
have the latter pattern you, the developer, are in the best position to
know about it and write optimal code if it matters. Your proposal
requires adding a second code path to every single queryset method, so
it's going to be a fair few extra lines of code. The functionality would
have to be a huge win to be worthwhile, since it's only a few lines to
write it directly in Python each time.
Malcolm
--
Two wrongs are only the beginning.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
