#13795: Add CACHE_KEY_PREFIX setting that prefixes the low-level cache API
-----------------------------------+----------------------------------------
Reporter: bruth | Owner: bruth
Status: assigned | Milestone:
Component: Cache system | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
-----------------------------------+----------------------------------------
Comment (by bruth):
Replying to [comment:3 russellm]:
> 1. I think the _key() utility method should actually be public API, not
a private method. Although a cache prefix is the obvious use case, I'm
sure there are other potential uses -- modifying the cache key based on
language settings is one possibility that springs to mind. If we're going
to add a function for computing the cache key, it makes sense that it
should be exposed and documented.
Now named ``make_key()``. Added a docstring noting that this can be
overridden in subclassing for custom key making behavior.
> 2. The key_prefix argument in cache backend constructors needs to have
a default value (of ''). Any existing subclasses of a cache class won't be
passing down the key_prefix argument, so the default value needs to be
provided down.
Fixed.
> 3. When instantiating the default cache instance, you should use the
keyword argument by name (i.e., key_prefix=settings.CACHE_KEY_PREFIX).
This is just protection against backwards compatibility, plus a little bit
of readability.
Updated.
> 4. The tests are very thorough, but they miss one important test case
-- that the prefix is being used at all. The tests could be simplified
quite a bit, because there really no need to check the empty cache prefix
case -- that's a degenerate case of the non-empty cache prefix case.
However, it is important to check that when a cache prefix is in use, that
the same key *without* the prefix isn't a cache hit (unless the cache key
is empty). Much of the test duplication could be removed by making the
non-empty cache prefix the default testing case, adding an extra test to
ensure that the empty prefix case isn't a cache hit, and then adding a
separate test case that runs exactly one test for the empty prefix case.
I simplified things a bit. Rather than subclassing for each backend, I
merely added another test in BaseCacheTests to test for key clashes when
using the prefix vs. not since that is of greatest concern.
> 5. In the documentation for CACHE_MIDDLEWARE_PREFIX you should make
mention of the fact that the CACHE_MIDDLEWARE_PREFIX will be appended to
the CACHE_KEY_PREFIX - i.e., that CACHE_KEY_PREFIX is a global prefix.
Add a note to the CACHE_KEY_PREFIX section regarding
CACHE_MIDDLEWARE_KEY_PREFIX.
--
Ticket URL: <http://code.djangoproject.com/ticket/13795#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
