I'm against this, as it stops the developer thinking.
It also doesn't work on multi-site installations.
It also stops developers having the ability to use the cache at the
global granularity or to
use cache keys from other applications sometimes.
regards
Ian
On 04/04/2007, at 5:48 AM, Nowell
Hey Adrian,
I can definitely understand the hesitancy to add new settings :-)
I do think that your proposal to broaden the scope of the existing
CACHE_MIDDLEWARE_KEY_PREFIX is a good idea (I cannot think of a case
where the two settings would need to differ). I was trying to avoid
proposing a bac
On 4/3/07, Nowell Strite <[EMAIL PROTECTED]> wrote:
> Since it would be a global prefix, it would be transparent to the
> Django developer (if you want to assign your own prefix, then leave
> the settings.CACHE_KEY_PREFIX blank and do it yourself--
> cache.set(settings.MY_CACHE_KEY_PREFIX + key, v
Hey Jacob, I understand your point, but to play devil's advocate for a
second.
Example:
cache.get(settings.CACHE_KEY_PREFIX + key)
cache.set(settings.CACHE_KEY_PREFIX + key, value, timeout)
cache.delete(settings.CACHE_KEY_PREFIX + key)
cache.has_key(settings.CACHE_KEY_PREFIX + key)
Since it woul
On 4/3/07, Nowell Strite <[EMAIL PROTECTED]> wrote:
> Django currently supoorts COOKIE prefixes, as well as a
> CACHE_MIDDLEWARE_KEY_PREFIX, but I would find it immensely useful to
> have a prefix for all cache key entries (i.e. site's sharing a common
> caching mechanism, with overlapping keys th
Hey ya'll,
I noticed that the caching framework does not currently support
setting a CACHE_KEY_PREFIX that would automatically be prefixed to any
get/set/delete function call in the caching. I would be willing to
write the patch, I just wanted to make sure that I was not missing a
discussion threa
