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 [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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
