Thanks for the reply Russ. I think ultimately it comes down to the fact that it was difficult to figure out what was happening, where as the actual fix itself (as you mentioned below) is a simple 2 or 3 line code change.
Now that I've thought about it more, I totally agree that my original suggestion is not the right way forward. However, I think what would be beneficial is a section within the documentation that explicitly states that the key being specified, is not the key that will end up in memcache. Something like: "Be advised, the cached key will not be accessible from other non-django webapps accessing memcache directly. This is due to the key being mangled to include support for features such as 'version' and KEY_PREFIX. You can either prepend the appropriate string yourself (explanation goes here), or replace the method that generates they key to avoid it being mangled (explanation goes here)". If you'd be happy for this to be included in the docs, I'll go ahead and submit a patch. Cal On Sat, Nov 19, 2011 at 10:44 AM, Russell Keith-Magee < [email protected]> wrote: > On Sat, Nov 19, 2011 at 4:08 PM, Cal Leeming [Simplicity Media Ltd] > <[email protected]> wrote: > > Hi, > > Since the release of 1.3, Django has changed the way it generates the > > memcache key name. > > If I was to do: > > cache.set('hello', 'world', 300) > > It would actually store the result as ":1:hello". Obviously, this is > because > > the version number is stored, along with the key prefix. > > But, this inherently breaks legacy applications which share memcache > values > > between other webapps (e.g. php/memcache-python direct etc). It was also > > incredibly frustrating to try and work out why on earth Django was seeing > > the key, and another application was not. > > The release notes mention the fact that there were changes to caching; > it should perhaps be a little more explicit about the fact that keys > would not be compatible between 1.2 and 1.3. > > [1] https://docs.djangoproject.com/en/dev/releases/1.3/#caching-changes > > > Therefore, I would like to recommend either one of two things (a - > being my > > personal preference): > > a) If the version number is the 'default' and there is no KEY PREFIX, > then > > it won't attempt to prepend the key with ":1:", instead keeping it in its > > original format. > > -1 from me. One simple behavior is better than a behavior that > changes, even if those changes are predictable. > > > OR > > b) Make it easier for users to disable this feature via config (I > understand > > there is an explanation of how to use 'make_key', but it's not a very > > intuitive or friendly out-of-the-box approach) > > Can you give any suggestions on how to make this easier? At the > moment, you need to: > > 1) Define a 2 line function > > 2) Put the path to that function in a setting. > > This process is documented, along with an example of a cache key function. > > I'm all for making things simpler when they can be, but in this case, > I'm actually at a bit of a loss as to how this could be any simpler. > Suggestions welcome. > > Yours, > Russ Magee %-) > > -- > 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. > > -- 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.
