On 3/17/06, Luke Plant <[EMAIL PROTECTED]> wrote: > >>> len(connection.queries) > 3
This is by design. Every call to all() produces a new query set. This behaviour has been discussed a few times, usually in the context of renaming all() 'cached()', whether caching should be the default or an optional behaviour, and whether c.leaders should operate as a query set that hits the database (it doesn't currently). To fix your problem, you can say: >>> ldrs = c.leaders.all() > [Jason & Ruth Phillips] > >>> len(connection.queries) > 2 >>> ldrs > [Jason & Ruth Phillips] > >>> len(connection.queries) > 2 ie, all() returns a query set, with a cache that can be reused later (and it won't hit the database again). > This isn't great. But I've got a partially working solution. The first > step is to get rid of .all() for these lookups (hooray!), by making the > related object descriptor return a QuerySet subclass instance instead > of a Manager subclass instance. Again, look back at the archives. http://groups.google.com/group/django-developers/browse_thread/thread/4a6c67a2df095b43/bb00c30c7ba63bdf For the record, I would be +1 on Article.objects returning a non-cached query set, and Article.objects.all() returning a cached query set - however, at last count, I believe Adrian considered the matter closed. This thead also worked through a few other mechanics with caching. > The second step is to make the > descriptor objects cache the QuerySets once they have been created. I disagree here - the query set is the thing that has the cache, not the descriptor. Store and reuse the query set if you want to reuse the cache. Again, follow the thread (and the thread it refers to) for reasoning. > With my changes, the final line fails because the cache in p1 doesn't > know that all the objects have been deleted, and p1.article_set still > has a2 in it. It's not just deletion of course - Django's ORM doesn't > guarantee that any changes done in one place will be updated to others. Yes - and there is more than one place in the unit tests where this is already specifically worked around - e.g., line 68 of the many_to_one unit test specifically regets the object to refresh. I am about to commit a few more calls like this in my latest pass at descriptor fixes. > So, what do people think of these changes? We could add in some kind of > explicit 'freshen' calls into the tests to make them pass. This is an idea that I have been considering myself; adding a refresh() method to a model itself to allow an object to reload its contents from the database. Like Adrian said, it's not really a problem that most web apps will have, but a refresh() call can be safely ignored by all that don't need it, and would be very convenient to those limited cases that do (including the unit tests). Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
