On Thu, Dec 2, 2010 at 3:05 AM, Jacob Burch <jacobbu...@gmail.com> wrote: > >> * The timeout handling code should be abstracted behind >> _get_memcache_timeout(). That utility already exists to ensure the >> eccentricities of memcached timeout handling are supported, and I >> can't see an obvious reason why we can't put this check in there too. >> > > The problem is I can't think of a good way to force instant-expiring > sets in pylibmc. The only way to fake the response is to alter the > actual return value. 0 and all negative numbers, in pylibmc, set for > never expire. And even a timeout of 1 second currently causes the > cache template tag tests to fail.
I must be missing something here. All I was proposing was for the "if timeout < 0: return None" logic that is repeated in several places should be factored into the _get_memcache_timeout() call itself. As far as I can make out, there's no behavioral advantage to having that logic outside the function that implements all the other timeout munging behavior. I've forked your gist to show what I was driving at with my review comments: https://gist.github.com/7dd35aa976375183ed16 >> Now for the can of worms -- I'm wondering if there is some potential >> for doing a weasel job with respect to infinite timeouts. You >> rectified the library to ensure that negative timeout values are >> turned into instant expiration, which is for consistency with the >> other memcache backends. >> >> However, I can't find any specific reference in Django's docs to the >> behavior of cache backends when timeout is negative. I'm wondering if >> this might be the weasel way into getting infinite timeouts -- even if >> it's in conjunction with a clause like "if the backend supports them". > > The only reference is implicit in the tests. the first ten or so tests > for cache template tag use negative timeouts as a way to check that > the cache tag doesn't pull in expired data. The fact that the tests validate negative timeouts does pose a bit of a problem. I'll give this a bit more thought, but there's no reason that this should hold up getting pylibmc support into trunk. The one piece standing between this and trunk is the reworking required for CACHE_SETTINGS -- have you made any progress on this? 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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
