On 2/12/06, Robert Wittams <[EMAIL PROTECTED]> wrote: > I was imagining that any call that created a new query set (ie modified > some search parameter) would turn caching on. Of course, this wouldn't > cache across calls that happened to end up with the same query. ( That > would necessitate hanging the cache off a context variable as I talked > about before).
I think I'm missing something here - mod the dislike of all(), how does this differ from what happens right now? Article.objects.all() (name problems notwithstanding) returns a QuerySet with a cache that is populated the first time the query is interrogated. If you apply a filter, you get a new Query Set. If you don't interrogate for data, there is no cache populated. Admittedly, the downside here is that end user doesn't have much control over the clearing/repopulation of the cache, or disabling use of the cache altogether, on any particular QuerySet. However, the user can always clone a query to get a fresh query with a clean cache; alternatively, we could add QuerySet.clear_cache(), QuerySet(cache=False), and similar mechanisms to QuerySet. > The only real 'trouble' situation is the manager that is stored in the > class, I think. Which brings us back to why all() was introduced in the first place - problems with the lifespan of the cache of the 'manager as QuerySet' object. While I conceed that Article.objects -> set of all objects is a very nice mental model, I can see us working ourselves into knots trying to overcoming caching problems on an Article.objects 'manager QuerySet'. all() isn't quite as nice as a mental model, but it certainly doesn't offend me, and it seems to have a lot less problems (or at least is restricted to problems inherent in any caching mechanism). Russ Magee %-)
