Luke Plant wrote: > I'm actually more bothered by the .all() required everytime you use > related lookups to actually get the objects (which isn't what this > thread is really about, I know). There is no reason for it technically > (the reason for Managers was caching and persistence), and it kind of > breaks the name - it is no longer an 'article_set', it is something > that gives you an article set if you do 'all()' on it. Since > 'article_set' could easily be accessed in templates (I have lots of > instances in my own project), I think using it needs to be simpler.
I still think this would be a lot easier if we didn't use the name 'all()' to mean 'give me a cached version of this query'. '.cached()' would seem more sensible. Managers would be uncached query sets by default, whereas related object sets would reasonably be cached by default ( A class is going to stick around between requests. An instance isn't unless you take heroic measures to ensure it does ). So I would suggest: Article.objects: is a query set that supports all the normal operations, but is uncached Article.objects.cached(): is a query set that is cached. Otherwise the same as Article.objects my_article.author_set a query set that is cached. If there were a convincing use case, maybe a .uncached() method would be sensible. Anyway, I think .all() is a very confusing term for this, and I hope it goes away... The other solution to this is to have a 'context' variable in the vein of PEP 343, which the caches would be attached to (rather than being in the caches themselves). This variable would be set at the beginning/end of requests, and also when switching threads in a multi threaded server, if any exist... This way the .cached() would be unnecessary - the cache would be scoped to the request in the web context, and caching contexts could be explicitly set in other contexts.
