On 7/5/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > It would be super cool to invalidate the cache (or not) at the > moment I update the data, but it's not mission critical.
How's the data updated? Need to know how to get the update info to the cache. :) > Long story short, my current approaches haven't yielded any fruit. I'm > not sure that I can cache one view two different ways by using the > cache_page function. Perhaps I need to dig a little deeper into the > caching mechanisms? As a hack, you could have a stub view that just decides if it's the current month or not, then dispatch either of 2 real views, each with its own cache_page. For an actual solution, more detail's needed. How many other parameters from the request come into play? If a small number of permutations, you could bake all the data (that is, pull requests into a flat file to be served cheaply later, in which "invalidating cache" is deleting a file). If you decide to use the low-level cache due to too many permutations, this is the general approach: expensive_thing = cache.get(some_key) if not expensive_thing: expensive_thing = expensive_process cache.set(some_key, expensive_thing, cache_timeout) You can, of course, do that as much as you want. I have some views that do two or 3 phases, in which I cache a whole resultset, then munge or whittle it depending on parameters and cache that bit with a more fine-grained key. Cheers, Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---