skip to navigation
skip to content

django-cachepurge 0.3

Django Middleware and utilities that send "PURGE" request to an upstream cache

What is it?

This package allows django to purge HTTP cache when a model instance is changed or deleted. It does this by sending “PURGE” requests to one or more upstream HTTP cache (such as Squid or Varnish). This is inspired by Plone CacheFu components.


In put ‘django_cachepurge’ before any other application; else it may fail to register some models:


Add the middleware:




or if you have more than one cache:



Urls are extracted from models instances on post_save signal. Two sources are used:

  • instance.get_absolute_url(), if it exists
  • instance.get_purge_urls(), if it exists. The application expects a list of absolute paths similar to what is provided by get_absolute_url().

Purge request is sent when response has been computed: if an exception occurs the urls are not purged. Purge requests are asynchronous: worker threads handle that so that we don’t have wait to complete all requests before returning the response.

Cache configuration

The cache must be configured to accept and handle “PURGE” requests from the server where the django application is hosted.


Bertrand Mathieu, Author

Change history

0.3 - 2011-04-01

  • Compatible with Django 1.3: don’t import django.utils.thread_support
  • catch NoReverseMatch exception when trying to find an instance’s url

0.2 - 2010-11-22

  • Accept to purge only site urls, converted if needed into their relative form (i.e, “/some/path/”)

0.1a - 2009-05-25

  • 0.1a: 0.1 released missed some files
  • Initial release
File Type Py Version Uploaded on Size
django-cachepurge-0.3.tar.gz (md5) Source 2011-04-01 9KB