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 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, value)... but since you
will always want to prefix your cache keys (in the case of a shared
caching mechanism) I think it would be beneficial to implement this--
we already do for set_cookie/get_cookie/delete_cookie, so why not
here?

I think the same logic/discussion that comes into play with the
set_cookie prefix applies here as well, don't you think?

Thanks!
Nowell

On Apr 3, 2:29 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> 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 that hold different data)
>
> I'm not a big fan of having my cache keys transparently changed. I
> think as a point of philosophy Django shouldn't mess with things like
> that.
>
> Besides, doing it yourself couldn't be easier::
>
>     cache.set(settings.CACHE_KEY_PREFIX + key, value, timeout)
>
> Jacob


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to