On Fri, 2008-11-28 at 08:18 -0600, Jeremy Dunck wrote: > 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.
[...] > Thoughts? I kind of like the idea. You've certainly identified a problem area: to construct a valid cache key requires a lot of knowledge. I haven't thought through all the particulars yet, but something should be possible. You seem to have separated out the creating the cache key (which the end object can only really know how to do, since only it knows which of the factors are likely to affects its own variability) from the providing of the information, which is good. Not sure what the API might look like, but it shouldn't be too hard. A call to a "register the necessary information" function on a per-request basis and the registration blob just holds it in memory for that request/response cycle. Particularly as low-level partial-response caching is used more and more (as people become aware of the benefits and used to the patterns that it assists) this will be a step in the right direction. I think it has potential. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
