On Sun, Nov 13, 2011 at 11:35 AM, Cal Leeming [Simplicity Media Ltd] <[email protected]> wrote: > +1 on hashing the key. > Just my two cents worth but, the way our company does it as standard is > something like this: > import hashlib > def generate_key(*args, **kwargs): > return hashlib.sha224(pickle.dumps([args, kwargs])).hexdigest() > Then you can do stuff like: > lol = YourModel.objects.all()[0] > generate_key('YourModel', lol.id, 'other stuff')
Or, alternatively, you could use the cache-key transformation feature that Django has baked in: https://docs.djangoproject.com/en/1.3/topics/cache/#cache-key-transformation Using hashes for memcache keys isn't a completely no-brainer choice -- there are tradeoffs. For example: * Hashes aren't free to compute. If you have to generate a lot of them (and you need to generate them on both read and write), there's a CPU cost. Caching is supposed to be a mechanism by which you exchange CPU load for memory; putting a CPU intensive operation in that path isn't necessarily a good idea. * Your memcache keys aren't human readable, and aren't reversible to human-readable values, so it's potentially harder to debug caching problems. * You introduce a potential collision problem. In practice, this probably isn't very likely, but it's *possible*; if you don't use hashes, it isn't possible at all. Therefore, Django provides a simple and conservative default, but provides all the tools you need to override the default behavior. If you decide on a per-site basis that hashing cache keys is a worthwhile activity, you can implement that behavior easily. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en.
