I did notice this bug, but it went away when I switched to cmemcache (a much
faster alternative if its availble to you).
On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
>
> When using the low-level cache and memcache as the backend, you're
> likely to run into this stack trace:
>
> ...
> File "/pegasus/code/current/django/core/cache/backends/memcached.py" in
> set
> 48. self._cache.set(key, value, timeout or self.default_timeout)
> File "/usr/lib/python2.5/site-packages/memcache.py" in set
> 305. return self._set("set", key, val, time)
> File "/usr/lib/python2.5/site-packages/memcache.py" in _set
> 328. fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time,
> len(val), val)
>
> UnicodeDecodeError at /
> 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in
> range(128)
>
> What's going on here is that the memcache.py library does this with
> the passed parameters:
>
> fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
>
> Since "key" is often a unicode string, it infects, as it were, the
> rest of the line, forcing "val" to be encoded, then decoded.
>
> It may be that only the memcache backend has this problem, but the
> general solution I'd suggest is to use smart_str on the key given to
> each low-level cache's backend set method. Works-for-me.
>
> It may also make sense to run on the value, but I imagine that has a
> significant overhead, and I haven't had a problem with it yet....
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
