To reproduce this, set the default cache backend to
`django.core.cache.backends.db.DatabaseCache` and call `incr()` on the
cache. Although,
[https://github.com/django/django/blob/df8d8d4292684d6ffa7474f1e201aed486f02b53/django/core/cache/backends/base.py#L186
the bug is easy to spot] since `.set(...)` is being called without passing
a timeout.
I'm assuming this is a bug since `LocMemCache` doesn't reset the timeout,
the docs don't mention anything about it and it seems like a surprising
behaviour to me.
Django 1.8 and 1.9 are affected by this.
--
Ticket URL: <https://code.djangoproject.com/ticket/26619>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I guess a possible resolution would be to add a `timeout` argument to
those methods? I don't think we can increment/ decrement them while
keeping the current timeout?
--
Ticket URL: <https://code.djangoproject.com/ticket/26619#comment:1>
Comment (by nitely):
Honestly, I'm not sure. Your proposal is consistent with `set()`. However,
memcached and Redis don't set a timeout when incr/decr. I don't know of a
in-memory cache that does that.
The database backend could just update instead of doing a get/set, so it
could keep the timeout (and also be atomic), not sure why it was not
implemented that way. The filecache backend can also leave the timeout
untouched, AFAICT.
If I were to design the cache system from scratch I'd just `raise
NotImplementedError` within the incr/decr of the base backend. But at this
point, I don't know how many third-party libs that would break.
--
Ticket URL: <https://code.djangoproject.com/ticket/26619#comment:2>
* stage: Unreviewed => Accepted
Comment:
Some discussion on the DevelopersMailingList may be useful to decide on
how to proceed.
--
Ticket URL: <https://code.djangoproject.com/ticket/26619#comment:3>