This might help:
http://gist.github.com/425403
I have some similar code here: http://gist.github.com/439868
It might be better because it wraps an arbitrary cache backend adding
prefix handling, it's not limited to memcache.
It omits the prefix if the key name starts with the domain of the
current Site. This is important for us because sometimes we want to
share cache keys with other clients, and in this situation they
shouldn't be aware of the particular prefix in use.
It lacks coverage of new cache methods added in 1.2.
Uhm, http://gist.github.com/425403 does indeed support an arbitrary
backend, there's just a call to _get_memcache_timeout() which should
be changed in order to make it completely backend agnostic. I left
"*args, **kwargs" signatures everywhere to avoid dealing with
parameters.
Apologies for not weighing in sooner -- I think this is a reasonable
feature proposal; I've just marked the ticket as accepted. The patch
looks pretty good too, although I've got a couple of light polish
requests. I've attached comments on the ticket.
Yours,
Russ Magee %-)
Looks good. A couple of questions/comments:
* Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't
quite see the point of a separate setting, so unless you can think of a
good reason to have both I'd suggest we deprecate
CACHE_MIDDLEWARE_KEY_PREFIX in favor of CACHE_KEY_PREFIX globally.
* In a few places you have functions defined like::
def get_cache(backend_uri, key_prefix=settings.CACHE_KEY_PREFIX):
This is a bad idea: it forces the loading of settings at import time,
meaning that if you've not defined DJANGO_SETTINGS_MODULE or called
settings.configure() you can't even import the cache module.
As a rule, you should avoid evaluating settings at import time, so in
this case you'd do something like::
def get_cache(backend_uri, key_prefix=None):
if key_prefix is None:
key_prefix = settings.CACHE_KEY_PREFIX
...
* 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); you may 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.
Thanks for your work - this looks good.
Jacob
On Wed, Aug 4, 2010 at 8:06 AM, Byron <bjr...@gmail.com> wrote:Updated the patch http://code.djangoproject.com/ticket/13795
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:* 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); you may 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.
import timeThis 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?
CACHE_KEY_PREFIX = "dev-ned-%s" % time.time()