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. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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.
