On Saturday, November 19, 2011, Cal Leeming [Simplicity Media Ltd] < [email protected]> wrote: > 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.
It's certainly worth an update to the docs - both the release.notes where the change was introduced, and the cache docs itself. I'd probably avoid using pejorative terms like "mangled" though; that makes it sound like the result is undesirable or unintended. 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.
