Yea, I definitely agree that it is a simple solution. I think the the fact that the setting is optional and would not break any existing code, it should be included since it "feels" like a common case... we shall leave it up to the core devs to determine this.
On Jun 1, 7:14 pm, Gabriel Hurley <gab...@gmail.com> wrote: > 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.
