Browse files

Fixed #6464 -- Added incr() and decr() operations on cache backends. …

…Atomic on Memcache; implemented as a 2 stage retrieve/update on other backends. Includes refactor of the cache tests to ensure all the backends are actually tested, and a fix to the DB cache backend that was discovered as a result. Thanks to Michael Malone for the original patch.

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
1 parent 1d8e6ea commit 638dbc3e8320652ba3bd759e0ac1d28590402096 @freakboy3742 freakboy3742 committed Mar 11, 2009
@@ -65,6 +65,24 @@ def has_key(self, key):
return self.get(key) is not None
+ def incr(self, key, delta=1):
+ """
+ Add delta to value in the cache. If the key does not exist, raise a
+ ValueError exception.
+ """
+ if key not in self:
+ raise ValueError, "Key '%s' not found" % key
+ new_value = self.get(key) + delta
+ self.set(key, new_value)
+ return new_value
+ def decr(self, key, delta=1):
+ """
+ Subtract delta from value in the cache. If the key does not exist, raise
+ a ValueError exception.
+ """
+ return self.incr(key, -delta)
def __contains__(self, key):
Returns True if the key is in the cache and has not expired.
@@ -64,6 +64,7 @@ def _base_set(self, mode, key, value, timeout=None):
cursor.execute("INSERT INTO %s (cache_key, value, expires) VALUES (%%s, %%s, %%s)" % self._table, [key, encoded, str(exp)])
except DatabaseError:
# To be threadsafe, updates/inserts are allowed to fail silently
+ transaction.rollback()
return False
@@ -45,3 +45,8 @@ def get_many(self, keys):
def close(self, **kwargs):
+ def incr(self, key, delta=1):
+ return self._cache.incr(key, delta)
+ def decr(self, key, delta=1):
+ return self._cache.decr(key, delta)
@@ -184,7 +184,7 @@ Patch style
An exception is for code changes that are described more clearly in plain
English than in code. Indentation is the most common example; it's hard to
read patches when the only difference in code is that it's indented.
Patches in ``git diff`` format are also acceptable.
* When creating patches, always run ``svn diff`` from the top-level
@@ -402,7 +402,7 @@ translated, here's what to do:
* Join the `Django i18n mailing list`_ and introduce yourself.
- * Create translations using the methods described in the
+ * Create translations using the methods described in the
:ref:`i18n documentation <topics-i18n>`. For this you will use the
`` makemessages`` tool. In this particular case it should
be run from the top-level ``django`` directory of the Django source tree.
@@ -697,9 +697,9 @@ repository:
first commit the change to library Y, then commit feature X in a separate
commit. This goes a *long way* in helping all core Django developers
follow your changes.
- * Separate bug fixes from feature changes.
+ * Separate bug fixes from feature changes.
Bug fixes need to be added to the current bugfix branch (e.g. the
``1.0.X`` branch) as well as the current trunk.
@@ -782,6 +782,10 @@ dependencies:
* Textile_
* Docutils_
* setuptools_
+ * memcached_, plus the either the python-memcached_ or cmemcached_ Python binding
+If you want to test the memcached cache backend, you will also need to define
+a :setting:`CACHE_BACKEND` setting that points at your memcached instance.
Each of these dependencies is optional. If you're missing any of them, the
associated tests will be skipped.
@@ -791,6 +795,9 @@ associated tests will be skipped.
.. _Textile:
.. _docutils:
.. _setuptools:
+.. _memcached:
+.. _python-memcached:
+.. _cmemcached:
To run a subset of the unit tests, append the names of the test modules to the
```` command line. See the list of directories in
@@ -862,28 +869,28 @@ for feature branches:
1. Feature branches using a distributed revision control system like
Git_, Mercurial_, Bazaar_, etc.
- If you're familiar with one of these tools, this is probably your best
+ If you're familiar with one of these tools, this is probably your best
option since it doesn't require any support or buy-in from the Django
core developers.
However, do keep in mind that Django will continue to use Subversion for
the foreseeable future, and this will naturally limit the recognition of
your branch. Further, if your branch becomes eligible for merging to
trunk you'll need to find a core developer familiar with your DVCS of
choice who'll actually perform the merge.
If you do decided to start a distributed branch of Django and choose to make it
public, please add the branch to the `Django branches`_ wiki page.
2. Feature branches using SVN have a higher bar. If you want a branch in SVN
itself, you'll need a "mentor" among the :ref:`core committers
<internals-committers>`. This person is responsible for actually creating
the branch, monitoring your process (see below), and ultimately merging
the branch into trunk.
If you want a feature branch in SVN, you'll need to ask in
- `django-developers`_ for a mentor.
+ `django-developers`_ for a mentor.
.. _git:
.. _mercurial:
@@ -894,7 +901,7 @@ Branch rules
We've got a few rules for branches born out of experience with what makes a
-successful Django branch.
+successful Django branch.
DVCS branches are obviously not under central control, so we have no way of
enforcing these rules. However, if you're using a DVCS, following these rules
@@ -908,19 +915,19 @@ rules are broken.
* Only branch entire copies of the Django tree, even if work is only
happening on part of that tree. This makes it painless to switch to a
* Merge changes from trunk no less than once a week, and preferably every
couple-three days.
In our experience, doing regular trunk merges is often the difference
between a successful branch and one that fizzles and dies.
If you're working on an SVN branch, you should be using ``_
to track merges from trunk.
* Keep tests passing and documentation up-to-date. As with patches,
we'll only merge a branch that comes with tests and documentation.
Once the branch is stable and ready to be merged into the trunk, alert
@@ -162,7 +162,7 @@ cache is multi-process and thread-safe. To use it, set ``CACHE_BACKEND`` to
``"locmem:///"``. For example::
CACHE_BACKEND = 'locmem:///'
Note that each process will have its own private cache instance, which means no
cross-process caching is possible. This obviously also means the local memory
cache isn't particularly memory-efficient, so it's probably not a good choice
@@ -439,6 +439,33 @@ of clearing the cache for a particular object::
>>> cache.delete('a')
+.. versionadded:: 1.1
+You can also increment or decrement a key that already exists using the
+``incr()`` or ``decr()`` methods, respectively. By default, the existing cache
+value will incremented or decremented by 1. Other increment/decrement values
+can be specified by providing an argument to the increment/decrement call. A
+ValueError will be raised if you attempt to increment or decrement a
+nonexistent cache key.::
+ >>> cache.set('num', 1)
+ >>> cache.incr('num')
+ 2
+ >>> cache.incr('num', 10)
+ 12
+ >>> cache.decr('num')
+ 11
+ >>> cache.decr('num', 5)
+ 6
+.. note::
+ ``incr()``/``decr()`` methods are not guaranteed to be atomic. On those
+ backends that support atomic increment/decrement (most notably, the
+ memcached backend), increment and decrement operations will be atomic.
+ However, if the backend doesn't natively provide an increment/decrement
+ operation, it will be implemented using a 2 step retrieve/update.
That's it. The cache has very few restrictions: You can cache any object that
can be pickled safely, although keys must be strings.
Oops, something went wrong.

0 comments on commit 638dbc3

Please sign in to comment.