Be aware that the way the cache key is constructed changed a bit. I'm
also invalidating template fragments when models used for rendering
changed, and found this while randomly reading changesets:
It used to be: fragment_name:additional:arguments:seperated:by:colons
Now it is:
On Mon, 2009-08-03 at 01:00 -0400, Nick Fishman wrote:
> > and suggests otherwise). It might not be too difficult to add support
> > for an optional timeout, although the error checking requires a lot of
> > care.
>
> I think that's the main problem. Since arguments to {% cache %} aren't
>
> and suggests otherwise). It might not be too difficult to add support
> for an optional timeout, although the error checking requires a lot of
> care.
I think that's the main problem. Since arguments to {% cache %} aren't
named, it doesn't seem possible to differentiate {% cache 500 key1
key2
On Sun, 2009-08-02 at 04:25 -0400, Nick Fishman wrote:
> I was wondering if it's possible to not specify the expiration time
> when using the {% cache %} tag to cache template fragments. With the
> low-level API, cache entries will expire after a timeout configured in
> CACHE_BACKEND. Is it
I was wondering if it's possible to not specify the expiration time when
using the {% cache %} tag to cache template fragments. With the low-level
API, cache entries will expire after a timeout configured in CACHE_BACKEND.
Is it possible to use the same default when caching template fragments?
In
5 matches
Mail list logo
