Binding signals to abstract models

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.

• managers
• models
• cache
• model
• manager
• signals
• abstract
• signal
• contribute_to_class

Thu 25 Apr 2024 Read More

A wrapper around cache_page making it optional

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.

• cache
• caching
• cache_page

Mon 14 Feb 2022 Read More

Django Online Now Users - Middleware

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

• middleware
• django
• session
• cache

Wed 05 Jan 2022 Read More

Caching Decorator

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.

• cache
• decorator
• speed
• caching
• fast

Wed 05 Jan 2022 Read More

Per-Instance On-Model M2M Caching

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.

• models
• cache
• m2m
• caching

Wed 05 Jan 2022 Read More

Cachable Django Paginator

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).

• django
• cache
• pagination

Fri 23 Feb 2018 Read More

Automatic Memoization Decorator

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

• cache
• memoize

Tue 15 Aug 2017 Read More

Reset cache between tests

I don't understand why the cache is accumulated between the tests. I thought one of the axioms of unit testing is that the tests should not affect each other. Couldn't find anything that explains why it's done this way but it seems a bit strange. Anybody know if there's a reason or is this a reason for me to upload a patch to Django code?

• cache
• tests
• locmem
• setup

Sat 12 Sep 2015 Read More

Cache view by user (and anonymous)

Use this decorator in your views to cache HttpResponse per user, so each user has his own cache, instead of a shared one as `from django.views.decorators.cache.cache_page` does. Add this to use: from somewhere import cache_per_user @cache_per_user(ttl=3600, cache_post=False) def my_view(request): return HttpResponse("LOL %s"%(request.user)) All documentation inside the decorator are in brazilian portuguese, feel free to translate to english

• views
• cache
• decorator

Wed 12 Aug 2015 Read More

Deferrable function cache decorator

A variant of https://djangosnippets.org/snippets/2850/ that allows expensive calls to be deferred to an asynchronous process.

• cache
• memoize
• django-rq
• redis

Tue 10 Feb 2015 Read More

per-function cache decorator

This is a simple decorator which caches the result of a function call for the specified number of seconds, using Django's caching mechanism.

• cache

Wed 21 Jan 2015 Read More

Cached model property decorator (like @property)

This is a nice decorator for using the cache to save the results of expensive-to-calculate but static-per-instance model properties. There is also a decorator for when the property value is another model, and the contents of the other model should not be cached across requests. 3 levels of caching implemented: * outermost: django cache * middle: obj._cache (for multiple properties on a single object) * innermost: replace the attribute on this object, so we can entirely avoid running this function a second time.

• property
• cache
• decorator

Sat 17 Jan 2015 Read More

Parsed RSS into template var

loads a parsed RSS feed (with feedparser) into a variable of choice. Caching by the "cache" template tag.

• template
• tag
• templatetag
• cache
• rss
• parse

Tue 06 May 2014 Read More

Run and cache only one instance of a heavy request

I have many heavy views which run slowly when accessed at same time in multiple threads. I make this decorator to allow run only one view at the time and cache returned result. Other threads will wait to complete first thread and use response from the cache if executed thread put it to cache. Also I take idea of MintCache to refresh staled cache and return cached (stale) response while response refreshed in the cache. Usage: @single_cacheable(cache_timeout=60, stale_timeout=30, key_template='my_heavy_view-{arg1}-{arg2}') def heavy_view(request, arg1, arg2): response = HttpResponse() ... your code here # cache timeout may be set from inside of view response._cache_timeout = cache_time return responce The "key_template" is a template for cache key. Some my views have additinal parameter "cache_time" which set from parent page and request.path is different for these pages but they need to be cached not depending of this parameter. Variable "key_template" in the example used named agrument, if you have no named paramaters you need to use 'my_heavy_view-{1}-{2}-{...}' where {1},{2}, {...} arguments of view. The line with setting "key" variable may be changed to: key = "sc_"+request.get_full_path() if you need to take full URL path as cache key.

• cache
• decorator

Mon 09 Dec 2013 Read More

Function cache decorator

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

Fri 05 Jul 2013 Read More