Re: Caching template fragments without specifying expiration time

2009-08-03 Thread Reiner 

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: template.cache.fragment_name.args where args is md5
(additional:arguments:seperated:by:colons)

http://code.djangoproject.com/changeset?new=django%2Ftrunk%2Fdjango%2Ftemplatetags%2Fcache.py%4011068=django%2Ftrunk%2Fdjango%2Ftemplatetags%2Fcache.py%408533

On Aug 2, 10:25 am, 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 possible to use the same default when caching template fragments?
>
> In particular, I'd like to use model signals to invalidate cache entries.
> That way, entries won't be invalidated after an arbitrary time period, but
> rather when they're actually invalid. Nathaniel Whiteinge wrote on
> 2008-12-03 that the {% cache %} tag creates entries with keys
> "fragment_name:additional:arguments:seperated:by:colons", so this seems
> possible.
>
> Any thoughts?
>
> Nick
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Caching template fragments without specifying expiration time

2009-08-02 Thread Malcolm Tredinnick 

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
> named, it doesn't seem possible to differentiate {% cache 500 key1
> key2 %} from {% cache user.id key1 key2 %}. In the first case, 500
> represents a timeout. In the second case, user.id might resolve to 500
> and represent a _key_ rather than a timeout. I'm not sure of an
> elegant way to deal with this.

Right. I hadn't thought of (ab)using it like that to just cache a random
variable (why not do it in the view in that case?!). It's more intended
for caching rendered template fragments and I thought you'd be able to
tell when the first thing was a number it's a timeout and when it's a
string it's a template fragment.

> I'll probably stick with setting a large constant in a
> context_processor and using that as the "effectively expire never"
> time. I'd have to use a similar trick when using the low-level cache
> API, anyway.

Or you could do it the easy way and spend three minutes writing a
template tag that uses the default cache value. Remember, you are
*encouraged* to write your own template tags to scratch itches. You
already have an example to work from. :)

Regards,
Malcolm


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Caching template fragments without specifying expiration time

2009-08-02 Thread Nick Fishman 

> 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 %} from {% cache user.id key1 key2 %}. In the first case, 500
represents a timeout. In the second case, user.id might resolve to 500
and represent a _key_ rather than a timeout. I'm not sure of an
elegant way to deal with this.

I'll probably stick with setting a large constant in a
context_processor and using that as the "effectively expire never"
time. I'd have to use a similar trick when using the low-level cache
API, anyway.

Thanks,

Nick

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Caching template fragments without specifying expiration time

2009-08-02 Thread Malcolm Tredinnick 

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 possible to use the same default when caching
> template fragments?
> 
> In particular, I'd like to use model signals to invalidate cache
> entries. That way, entries won't be invalidated after an arbitrary
> time period, but rather when they're actually invalid. Nathaniel
> Whiteinge wrote on 2008-12-03 that the {% cache %} tag creates entries
> with keys "fragment_name:additional:arguments:seperated:by:colons", so
> this seems possible.

The "cache" template tag always requires a timeout (although the
docstring on the function in django.templatetags.cache.do_cache() lies
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. So you might want to have a swing at adding this support and open
an enhancement ticket with a patch in Trac if you get that far.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Caching template fragments without specifying expiration time

2009-08-02 Thread Nick Fishman 
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 particular, I'd like to use model signals to invalidate cache entries.
That way, entries won't be invalidated after an arbitrary time period, but
rather when they're actually invalid. Nathaniel Whiteinge wrote on
2008-12-03 that the {% cache %} tag creates entries with keys
"fragment_name:additional:arguments:seperated:by:colons", so this seems
possible.

Any thoughts?

Nick

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---