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.
django online users, usage: `{{ request.online_now }}` or `{{ request.online_now_ids }}`, complete tutorial: https://python.web.id/blog/django-count-online-users/, this snippet forked from: https://gist.github.com/dfalk/1472104
This is a modificated version of `CachedPaginator` by **daniellindsley** [https://djangosnippets.org/snippets/1173/](https://djangosnippets.org/snippets/1173/) ([web-arhive-link](https://web.archive.org/web/20150927100427/https://djangosnippets.org/snippets/1173/)). Which not only cache `result_objects`, but the `total_count` of the `queryset` too (usefull if computating the count is an expensive operation too).
A variant of https://djangosnippets.org/snippets/2850/ that allows expensive calls to be deferred to an asynchronous process.
This decorator will memoize the results of instance methods, similar to `django.util.functional.memoize`, but automatically creates a cache attached to the object (and therefore shares the life span of the object) rather than requiring you to provide your own. Note this is intended for instance methods only, though it may work in some cases with functions and class methods with at least one argument. This is useful for memozing results of model methods for the life of a request. For example: class MyModel(models.Model): #Fields here @auto_memoize def some_calculation(self): #some calculation here return result
Allows you to make an arbitrary function's results cached for a period of time (also known as memoize).
Clear all cache set on memcached
This is caching mechanism augmented to help address a number of common pitfalls in caching: cache stampeding, simultaneous expiry, cache invalidation, and the storing of None as a legitimate value. No doubt the automatic key generation could stand to be simplified, but it works.
@cache(60) def heavy_computation(): for x in xrange(10000000): pass # just waste some time` The result of `heavy_computation` calls will be cached for 60 seconds. This cache decorator does not use the Django cache backend and uses the local memory instead.
Based on [snippet #1212](http://djangosnippets.org/snippets/1212/) along with it's comments. Replaced the for loop with translate. example usage: from django.core.cache import cache from mysnippet import cache_key_clean expensive_func = lambda x: 'x{0}x'.format(x) input_string = "I wanted a nice value." key = cache_key_clean(input_string) result = cache.get(key) if result is None: result = expensive_func(input_string) cache.set(key, result)
A decorator to bypass per-site cache if the user is authenticated. Based on django.views.decorators.cache.never_cache.
Django later than 1.3 (not sure of exact version) wasn't using prefix settings in cache tags or functions used in views. Just for whole page caching. This is small custom cache snippet based on memcached.CacheClass. Feel free adding any comments.
Intro ----- I found a question on SO for which Justin Lilly's answer was correct but not as thorough as I'd like, so I ended up working on a simple snippet that shows how to bind signals at runtime, which is nifty when you want to bind signals to an abstract class. Bonus: simple cache invalidation! Question -------- [How do I use Django signals with an abstract model?](http://stackoverflow.com/questions/2692551/how-do-i-use-django-signals-with-an-abstract-model) I have an abstract model that keeps an on-disk cache. When I delete the model, I need it to delete the cache. I want this to happen for every derived model as well. If I connect the signal specifying the abstract model, this does not propagate to the derived models: pre_delete.connect(clear_cache, sender=MyAbstractModel, weak=False) If I try to connect the signal in an init, where I can get the derived class name, it works, but I'm afraid it will attempt to clear the cache as many times as I've initialized a derived model, not just once. Where should I connect the signal? Answer ------ I've created a custom manager that binds a post_save signal to every child of a class, be it abstract or not. This is a one-off, poorly tested code, so beware! It works so far, though. In this example, we allow an abstract model to define CachedModelManager as a manager, which then extends basic caching functionality to the model and its children. It allows you to define a list of volatile keys that should be deleted upon every save (hence the post_save signal) and adds a couple of helper functions to generate cache keys, as well as retrieving, setting and deleting keys. This of course assumes you have a cache backend setup and working properly.
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.
Template: {% load cache %} {% cache 1800 posts blog.pk %} {# Show posts #} {% endcache %} Code: def view(request, pk): # Code blog = get_object_or_404(Blog, pk=pk) delete_template_fragment_cache('posts', blog.pk) # Code
78 snippets posted so far.