On Wed, Aug 4, 2010 at 8:06 AM, Byron <bjr...@gmail.com> wrote:
> Updated the patch http://code.djangoproject.com/ticket/13795
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
--
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.
