[Django]-Template fragment caching doesn't seem to work for some custom template tags

If the template fragment you’re trying to cache can’t be pickled, memcached won’t be able to store it and will raise an exception. From what I can gather, exceptions generated when rendering Django templates are suppressed. Since your custom tag is doing HTTP requests, maybe socket objects (which can’t be pickled) are getting stored to the template fragment somehow.

If this is the case, the only way around it I can think of would be to modify the custom tag to get rid of any leftover socket objects.

Have you tried to use a different name for the cache fragment? There could be a problem with using request.user.username for a couple of reasons:

• If a user is not signed in,
  request.user.username could be empty,
  resulting in a non-named cache
  fragment

• If a user is signed in, this will
  call the 3rd party template tag at
  least once for each user every 3
  mintues

Maybe it’s worth trying to rename the cache fragment name to test:

{% cache 500 customxml %}

I’d also try loading of the 3rd party template tag outside the cache tag like so:

{% load cache third_party_custom_tags %}
{% cache 500 request.user.username %}
{% expensive custom tag set that gets stuff from a third party server via xml %}
{{ some.stuff}}
{% endcache %}

What I’m not sure of is if the cache framework caches the results of a template tag. If that doesn’t work, I’d take a look at what the template tag is doing under the hood and re-implement the template tag using Django’s low-level cache.

I think the problem is the custom tag, as you suggested.

I disagree that the request.user.username is a problem, as the documentation for the subject actually gives that as an example, and I have used it with internal caching (number of posts, for instance), in testing, and it worked fine.

The low level cache is potentially useful, but I would take a look at your custom tag to see what wouldn’t be caching. Without the code it’s hard to guess, but my guess would be something like the time, or some other variable, is being returned whic his causing it to force an update (if the XML pulls any data that changes Django may force an update, depending on other settings). I’ve had mixed results with Django’s caching, so I would have a look at your XML feed(s) to see if it’s causing anything to stop caching.

I don’t think this has anything to do with the custom tag.

We endded up rewriting the Django caching tag because we needed more control than was possible with the one that was supplied. You might make a copy of it yourself and stick some debugging print statements into it. In particular, check the filename (assuming you are caching to files) and see what is being generated. It could be that it is changing when it shouldn’t (for some unknown reason) and that would mean that it is always needing to re-render then enclosed block.

Look in django/templatetags/cache.py. It’s only 63 lines of code.