It seems like cache keys need to be created using various cross-cutting bits of data. As an example, maybe I have localized data, and any caching should include the requestor's locale, but also the content type / object ID, and maybe some other consumer differentiation.
This sort of key generation is left to the application developer because it'd require a lot of cross-knowledge in the subsystems of Django. But even so, it seems like it'd be useful for Django to reduce the headache of this repetitive, boring task. I recently was reminded of this old concept of a blackboard: http://en.wikipedia.org/wiki/Blackboard_system The basic idea is that Items stashed on the blackboard could be used to generate cache keys from templates which are supplied from the app code. (I don't mean template in the django.template sense, but I guess that could work.) Different subsystems could provide various blackboard components, and of course, the answer to anyone making a key template which required that info would be to include that subsystem-- similar to auth middleware providing request.user. The template would be formatted (or rendered, I guess) with the blackboard as the context. from django.core.cache import cache cache.set("{{ request.path }}:news:latest";, ...) Or cache.set("%(request.path)s:news:latest";, ...) Or, for backwards compat and performance, cache.set could stay the same, and it could be: cache.format_set("%(request.path)s:news:latest";, ...) Thoughts? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
