A Django cache_page on steroids
Django ships with an awesome view decorator called cache_page which is awesome. But a bit basic too.
What it does is that it stores the whole view response in memcache and the key to it is the URL it was called with including any query string. All you have to do is specify the length of the cache timeout and it just works.Now, it’s got some shortcomings which django-fancy-cache upgrades. These “steroids” are:
- Ability to override the key prefix with a callable.Ability to remember every URL that was cached so you can do invalidation by a URL pattern.Ability to modify the response before it’s stored in the cache.Ability to ignore certain query string parameters that don’t actually affect the view but does yield a different cache key.Ability to serve from cache but always do one last modification to the response.Incrementing counter of every hit and miss to satisfy your statistical curiosity needs.
The documentation is here:https://django-fancy-cache.readthedocs.org/
You can see it in a real world implementation by seeing how it’s used on my blog here. You basically use it like this::
from fancy_cache import cache_page@cache_page(60 * 60)def myview(request): ... return render(request, 'template.html', stuff)
What I’m doing with it here on my blog is that I make the full use of caching on each blog post but as soon as a new comment is posted, I wipe the cache by basically creating a new key prefix. That means that pages are never cache stale but the views never have to generate the same content more than once.
I’m also using django-fancy-cache to do some optimizations on the output before it’s stored in cache.
