This manager use a local (in python dicts) cache for efficiency. It caches get requests and is better used with a context manager. I based my work on this previous snippet : https://djangosnippets.org/snippets/815/
Make `cache_page` optional, depending on the result of a callable. Uncomment the added lines if you want to make sure that the consumers don't know the page is cached – that means more hits on your end, but also a guarantee that they will always get the newest data asap.
This is a decorator which will gets Django to try the cache before computing the result of a function. It automatically builds the cache key as a hash of the function name and inputs, and allows you to set whatever timeout you want.
A simple model and admin entry for managing Cache table through the Django admin interface.
A very simple decorator that caches both on-class and in memcached: @method_cache(3600) def some_intensive_method(self): return # do intensive stuff` Alternatively, if you just want to keep it per request and forgo memcaching, just do: @method_cache() def some_intensive_method(self): return # do intensive stuff`
If you are like me and you find yourself often using M2M fields for tons of other on-model methods, in templates, and views alike, try using this quick and dirty caching. I show the use of a "through" model for the m2m, but that is purely optional. For example, let's say we need to do several different things with our list of beads, the old way is... # views.py necklace = Necklace.objects.get(id=1) bead = Bead.objects.get(id=1) if bead in necklace.beads.all(): # this bead is here! # template necklace.html {% for bead in necklace.beads.all %} <li>{{ bead }}</li> {% endfor %} ...which would hit the database twice. Instead, we do this: # views.py necklace = Necklace.objects.get(id=1) bead = Bead.objects.get(id=1) if bead in necklace.get_beads(): # this bead is here! # template necklace.html {% for bead in necklace.get_beads %} <li>{{ bead }}</li> {% endfor %} Which only does one hit on the database. While we could have easily set the m2m query to a variable and passed it to the template to do the same thing, the great thing is how you can build extra methods on the model that use the m2m field but share the cache with anyone down the line using the same m2m field. I'm by no means an expert, so if there is something here I've done foolishly, let me know.
Caches a view based on the users language code, a cache_key and optional function arguments. The cache_key can be a string, a callable or None. If it's None, the the name of the decorated function is used. You can pass a tuple `func_args` of arguments. If passed, these arguments are part of the cache key. See examples for details.
A cache decorator.
If any cache keys you generate include user (staff or public) supplied data, they may: be too long, contain invalid characters (at least by memcache's standards), or both. This helper will sub out any invalid characters and md5 the key if it's too long. Additionally, it'll insert the CACHE_MIDDLEWARE_KEY_PREFIX from django.conf.settings for you. In your memcache instances are used by multiple applications (Django or otherwise) this can help ensure your keys are unique to that a particular app on a particular site.
A subclassed version of the standard Django Paginator (django.core.paginator.Paginator) that automatically caches pages as they are requested. Very useful if your object list is expensive to compute. MIT licensed.
A simple helper function that clears the cache for a given URL, assuming no headers. Probably best used when wired up to a model's post_save event via signals. See [message to django-users mailing list](http://groups.google.com/group/django-users/msg/b077ec2e97697601) for background.
RowCacheManager is a model manager that will try to fetch any 'get' (i.e., single-row) requests from the cache. ModelWithCaching is an abstract base model that does some extra work that you'll probably want if you're using the RowCacheManager. So to use this code, you just need to do two things: First, set objects=RowCacheManager() in your model definition, then inherit from ModelWithCaching if you want the invalidation for free. If you are unusually brave, use the metaclass for ModelWithCaching and you won't even need the "objects=RowCacheManager()" line.
This is intended as an alternative to http://www.djangosnippets.org/snippets/155/ Put this in your own cache.py and import it instead of django.core.cache and use it the same way. We left out the "add" function but it shouldn't be too hard to make if you want it. From the above post: "The purpose of this caching scheme is to avoid the dog-pile effect. Dog-piling is what normally happens when your data for the cache takes more time to generate than your server is answering requests per second. In other words if your data takes 5 seconds to generate and you are serving 10 requests per second, then when the data expires the normal cache schemes will spawn 50 attempts a regenerating the data before the first request completes. The increased load from the 49 redundant processes may further increase the time it takes to generate the data. If this happens then you are well on your way into a death spiral MintCache works to prevent this scenario by using memcached to to keep track of not just an expiration date, but also a stale date The first client to request data past the stale date is asked to refresh the data, while subsequent requests are given the stale but not-yet-expired data as if it were fresh, with the undertanding that it will get refreshed in a 'reasonable' amount of time by that initial request."
13 snippets posted so far.