### Problem: you want to limit posts to a view This can be accomplished with a view decorator that stores hits by IP in memcached, incrementing the cached value and returning 403's when the cached value exceeds a certain threshold for a given IP.
Memcached Property Attributes ----------------------------- Setting the attribute will store the value in memcached; accessing the attribute will retrieve from memcached. Most useful as a way of simulating memcached "fields" on model instances. See the docstring for details.
A simple model and admin entry for managing Cache table through the Django admin interface.
This cache_page decorator can be used in replacement to Django's django.views.decorators.cache.cache_page. It resolves two problems: - invalidation (its cache key is not dependent of header nor request, then you can use model signals (or method 'put' in Google App Engine) to invalidate a URL or a list of them) - easier to scale (can be used at once memcached server by many differente servers) Feel free to show me where it can have problems or limitations. **Updated and improved a lot**
You may notice that using Google Analytics's 'urchin' with the CacheMiddleware and SessionMiddleware or AuthenticationMiddleware middleware classes means that nothing is ever cached. Google Analytics updates its cookies with every page view, and the Auth/Session middlewares add cookies to the caching engine's 'Vary' list. This means every page view is given a unique cache key. This middleware class will remove urchin's '__utmX' cookies from the request object before it hits the caching middleware. Put it at the top of your MIDDLEWARE_CLASSES in settings.py. nf / [email protected]
This tag appends the current git revision as a GET parameter to a media files so the web server can set an expires header far in the future. Your project must be structured such that MEDIA_ROOT/../.git exists. Usage: `<link rel="stylesheet" type="text/css" href="{% media myapp/css/base.css %}">`
Example usage: @cached('/data/something_hard') def get_something_complex(): .... return result dispatcher.connect(get_something_complex.invalidate, django.db.models.signals.post_save, Model)
this function invalidates a template-fragment cache bit. say you have: {% load cache %} {% cache 600 user_cache user.id %} something expensive here {% endcache %} maybe you want to force an update. With this function you can, just call: invalidate_template_cache("user_cache", user.id)
You can use this cache backend to cache data in-process and avoid the overhead of pickling. Make absolutely sure you don't modify any data you've stored to or retrieved from the cache. Make deep copies instead if necessary. The backend is basically identical to Django's stock locmem cache (as of r15852 - after 1.3rc1) with pickling removed. It has been tested with that specific Django revision, so basically it's >=1.3 compatible. See [Django ticket #6124](http://code.djangoproject.com/ticket/6124) for some background information.
Please see original snippet for commentary, all I did was add the caching of the arguments. http://www.djangosnippets.org/snippets/109/
Because the db caching doesn't support atomic operations, it was unsafe to store a list of 'keys' in a single key. So, rather than store the list, I just append each key with a specific tag, and then filter for it later. This means I don't need to worry too much about atomic usage with lists (i.e. queued requests). However - I still can think of many instances where I would need atomic usage, so I will probably implement this later on down the line. Hopefully, the atomic modifications will be accepted by the core devs. This also contains threaded cache cleaning, which means you no longer need to rely on requests to clean the cache (which would have potentially slowed the user query down), and will remove any cache entries past their expiry date every 3 minutes. Enjoy! Cal
Wraps existing cache configured as CUSTOM_CACHE_BACKEND and adds the SITE_ID to cache keys.
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.
You can use this cache all your functions' output, except dynamic things like connection.cursor.
cache_smart template tag is a drop in replacement for default cache tag by Django but with the added bonus to be more resistant against dog-pile/stampeding effect. This snippet uses a extra cache entry to store a stale time so we don't have to pickle/unpickle to store this extra value. If this cache entry returns None, as in expired it will reset the stale timeout 30 seconds in the future so further calls will just return the old value while this request is regenerating the new value. **warning** Don't use both cache template tags!