Personally, I solved this by writing a wrapper around
django.utils.cache that can be dropped in transparently. It was a
really simple matter to have it take a cache prefix (in my case from
settings.py) and pass that into the original functions.
It's a pretty easy fix if the core team agrees that it's useful. Seems
like the debate might be more around adding another setting for it/
where/how to manage that prefix.
All the best,
- Gabriel
On Jun 1, 8:12 am, Byron <bjr...@gmail.com> wrote:
> I ran into a seemingly common problem with cache key conflicts between
> two projects that both share an app and the same memcache instance. I
> would imagine that being able to optionally set a PROJECT_CACHE_PREFIX
> that is prepended to every key when setting/getting would be a nice
> transparent way of ensuring there are no conflicts. Obviously if the
> behavior is to share cache between projects, then no prefix can be
> specified.
>
> I want to get initial feedback, implications, etc. on this before I
> start writing a patch.
>
> Thanks,
> -Byron
--
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.
