Hi Eric - I took a look at django-newcache and I like the overall design. The whole thought behind my patch was a simple way to provide a global cache prefix since I had ran into key clashes among my projects (equivalent to your 'FLAVOR' setting). Your solution provides a much more flexible and extensible interface (especially with versioning).
What are your thoughts on adding these implementations to core? Of course these additional hooks can be implemented for the other backends as well. On Aug 4, 3:11 pm, "flo...@gmail.com" <flo...@gmail.com> wrote: > The most flexible way is to be able to specify a callable that runs on > each cache key before it is sent to the server. Then it's just up to > Django to provide a sensible default callable, but people could > override it to provide one which matches their own requirements. This > is what I do in django-newcache, at least. > > Thanks, > Eric Florenzano > > On Aug 4, 11:31 am, Ned Batchelder <n...@nedbatchelder.com> wrote: > > > > > On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote: > > > > On Wed, Aug 4, 2010 at 8:06 AM, Byron<bjr...@gmail.com> wrote: > > > >> Updated the patchhttp://code.djangoproject.com/ticket/13795 > > > > * Have you considered supporting "versioning" of keys to help with cache > > > invalidation? Eric Florenzano has been doing some interesting > > > experimenting along those lines in django-newcache > > > (http://github.com/ericflo/django-newcache);youmay want to look at the > > > code and/or talk to him about working some of his ideas back into your > > > key prefix proposal. At the very least, any changes we make to the > > > caching backend should allow the sorts of things he's doing to keep > > > working; ideally we should make those sorts of changes really easy to > > > make. > > > Couldn't versioning be handled by setting CACHE_KEY_PREFIX to include > > some varying data like the svn revision? We've got a cache key prefix > > hacked into our work environment, and I ensure my dev machine never gets > > stale cache data like this: > > > import time > > CACHE_KEY_PREFIX = "dev-ned-%s" % time.time() > > > This uses the start time of the dev server as part of the cache key so > > each invocation gets fresh data. In production, you'd use something > > different, but this illustrates the point. Or is there some more > > elaborate versioning being considered here? > > > --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
