On Thu, Jan 21, 2010 at 6:00 PM, Malcolm Box <malcolm....@gmail.com> wrote: > Hi, > > On Thu, Jan 21, 2010 at 7:35 AM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> >> On Thu, Jan 21, 2010 at 7:47 AM, Malcolm Box <malcolm....@gmail.com> >> wrote: >> > >> > I've got a simple question that I can't find the answer to: if the data >> > that a view depends on changes, does Django do anything smart to >> > invalidate >> > the cache for that view, or is it left to the programmer? > > >> >> >Your suspicions are correct - there is no systematic cache >> invalidation tied to Django's models. >> > Thanks for the confirmation! > >> >> If you want to invalidate a specific view, you will need to use the >> cache key tools to django.utils.cache to reconstruct the key for the >> view that needs to be invalidated. See the cache middleware for >> examples of usage. > > So a higher-level question - is this the prefered design approach - have the > views that alter data explicitly invalidate the views in the cache for the > ones who's data has been changed? > > It feels a bit too tightly coupled to me - and fragile if new views are > added. > > What's the recommended approach, or what have others done that's worked?
As with all interesting questions, the answer is "it depends" :-) You are correct that high level view caching is potentially fragile. It's a fine strategy if you have static content that isn't going to change very often (e.g., displaying an article for a newspaper), but it isn't so helpful if you have highly dynamic sites. The right solution will very much depend on the exact content you want to display, and the frequency with which various parts of it will be updated. You're going to need to analyse the way your site is being used in order to work out how to best exploit caching. Firstly, cache parts of pages, rather than full pages. The template cache tag could be helpful here. Another approach is to use the low level cache API to cache specific queries or computed responses. In both these cases, you are in completely control of the cache keys, so you can generate keys in a known space to make them easy to expire. Secondly, exploit the signals framework. Django issues signals whenever objects (and in Django 1.2, m2m relations) are updated; these signals give you an entry point to expire or update caches whenever a specific object is updated. Looking slightly more broadly, it *might* be possible to develop a generic app/library for cache expiry by wrapping the low level cache primitives with knowledge of the objects they are caching. However, this is green fields territory - I can't say I've ever seen a truly generic cache expiry framework. Yours, Russ Magee %-)
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
