Could you share your code with us?
Thanks you!

Lenz

On 2 Jun., 01:14, Gabriel Hurley <[email protected]> wrote:
> Personally, I solved this by writing a wrapper around
> django.utils.cachethat can be dropped in transparently. It was a
> really simple matter to have it take acacheprefix(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 thatprefix.
>
> All the best,
>
>     - Gabriel
>
> On Jun 1, 8:12 am, Byron <[email protected]> wrote:
>
> > I ran into a seemingly common problem withcachekey 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 sharecachebetween projects, then noprefixcan 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 [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