> 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. The cloned queryset's cache isn't invalid - it is a superset of the clone's cache, so why should we have to go back to the database again? That's unnecessary traffic. > > 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. > > Regards, > Malcolm > > -- > Atheism is a non-prophet organization.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 -~----------~----~----~----~------~----~------~--~---
