incr() on locmem cache resets the expiry time

[Malcolm Box]

On the locmem cache backend, calling incr() causes the key's timeout value to be reset to the default for the cache.

To reproduce:

• setup the default cache to be locmem and with a timeout of 1 second

  >> cache.set('key', 10, 300)
  >> time.sleep(1)
  >> cache.get('key')
  10
  >> cache.incr('key')
  >> time.sleep(1)
  >> cache.get('key')
  None
  

The cache should still contain the key at the last line.

The problem comes from the implementation of incr() in base.py which uses get() and set() to implement incr(). Since set() is called without a timeout, the cache default time is used.

[Alex Gaynor]

I'm assuming you consider this a bug, and would like it to not reset the expiry time ;) What's the justification for that behavior, memcached does it?

[Malcolm Box]

Yes, I consider this a bug.

As far as I can tell, memcached does not alter the expiry time of a key when incr()/decr() is called on it. Running the same test using a memcached cache backend, I get the value out at the end.

It seems highly counter-intuitive that updating a key's value should suddenly reset the timeout and cause the key to expire.

[Alex Gaynor]

Well, I think the locmem's behavior is a bit more intuitive personally, but we've generally tried to make the "stupid" backends do what memcached would do, since they're often used in development/testing. Marking as accepted.

[Malcolm Box]

Patch for locmem cache to bring incr() in line with memcached behaviour

[Michael Manfre]

locmem cache's incr() will no longer change timeout to mimic memcached

[Michael Manfre]

The original patch walked the expiration time forward by time.time() with each call to incr() and decr(). The new patch uses a special timeout value to skip setting the expiration time.

[Berker Peksag]

This bug already fixed in #17287.

See for the related commit:

​https://github.com/django/django/commit/1086a9a8455420b7167fe5195bca4c74883dcef0