On Sun, Nov 13, 2011 at 11:35 AM, Cal Leeming [Simplicity Media Ltd]
<cal.leem...@simplicitymedialtd.co.uk> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
