On Sun, Oct 16, 2011 at 8:26 AM, Alex Gaynor <[email protected]> wrote: > > > On Sat, Oct 15, 2011 at 8:23 PM, Russell Keith-Magee > <[email protected]> wrote: >> >> On Sunday, October 16, 2011, Cal Leeming [Simplicity Media Ltd] >> <[email protected]> wrote: >> > Hi Russell, >> > Thanks for the detailed response. It looks like both those solutions you >> > pasted have already dealt with this functionality - so thank you for >> > bringing these up. >> > Although it'd be really nice to see this in the core one day, is it >> > worth me pursuing to try and have something like this looked at again, or >> > would it be fighting a lost battle?? >> >> There is an old saying; there are only two hard problems in computer >> science - cache invalidation, naming things, and off-by-one errors. :-) >> >> The problem with #17 - and if you search the archives, it's well travelled >> territory - is that there isn't a single, >> obviously-correct-for-all-situations (or even -most-situations) answer for >> the cache invalidation problem. Any cache invalidation requires >> site-specific policies. And when you need site specific policies, that makes >> it difficult to provide generic solutions. >> >> I'm not going to say with 100% certainty that this will *never* get into >> core - on principle, query caching is obviously a useful technique. The >> issue is finding a solution that is appropriate for core. To be appropriate >> for inclusion in Django core, any candidate solution needs to be "clearly >> correct for the 90% case". Based on past discussions, I'm not convinced such >> a solution exists. >> >> The alternative is to provide in Django the infrastructure to make it easy >> to plug in a query cache. In this way, it would be the analog of multi-db. >> Multi-db requires a bunch of site specific policies too - that's why Django >> doesn't ship with any database routers. However, the core does contain the >> core functionality and extension points that allow you to define a router in >> user space. There are then third party libraries implementing common routing >> strategies, such as master/slave. >> >> Similarly, if anyone cares to propose a "core infrastructure layer" for >> query caching, *that* is something that might be suitable for inclusion in >> core. That said, evidence would seem to suggest that no such infrastructure >> is required - after all, there are already multiple third party libraries >> implementing query caching. >> >> Yours, >> 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 [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. > > I don't think we need another infrastructure layer, we already have one, we > call in the ORM and many people have built query caching layers on top of > it.
Quoting: "That said, evidence would seem to suggest that no such infrastructure is required - after all, there are already multiple third party libraries implementing query caching. " :-) Russ %-) -- 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.
