dj-pylibmc 0.6.4
Django cache backend using pylibmc
License: BSD
Keywords: django cache pylibmc memcached

==========
dj-pylibmc
==========


This package provides a memcached cache backend for Django using
`pylibmc <http://github.com/lericson/pylibmc>`_.  You want to use pylibmc because
it's fast.

This is a fork of the `django-pylibmc <https://github.com/jbalogh/django-pylibmc>`_
package.

Do you need dj-pylibmc?
---------------------------

Django now has a built-in pylibmc backend, and as of Django 1.11 also supports
the ``binary``, ``username`` and ``password`` options natively. As such, in most
cases the built-in backend should be used instead of dj-pylibmc, since it
will be more actively maintained.

To use Django's own backend, configure ``CACHES`` like so::

    CACHES = {
        'default': {
            'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
            'LOCATION': '127.0.0.1:11211',
        }
    }

See the
`Django documentation <https://docs.djangoproject.com/en/1.11/topics/cache/#memcached>`_
for details about using this cache backend.

Reasons to use dj-pylibmc instead, are:

- You would like to use pylibmc's compression feature
- You would rather pylibmc connection/server exceptions be caught/logged and not raised
  (though this may be `added upstream <https://code.djangoproject.com/ticket/28342>`_ soon).

Requirements
------------

dj-pylibmc requires pylibmc 1.4.1 or above. It supports Django 2.2 through
3.1, and Python versions >=3.6, <3.9

Installation
------------

Get it from `pypi <http://pypi.python.org/pypi/dj-pylibmc>`_::

    pip install dj-pylibmc

or `github <http://github.com/RegioHelden/dj-pylibmc>`_::

    pip install -e git://github.com/RegioHelden/dj-pylibmc.git#egg=dj-pylibmc


Usage
-----

Your cache backend should look something like this::

    CACHES = {
        'default': {
            'BACKEND': 'dj_pylibmc.memcached.PyLibMCCache',
            'LOCATION': 'localhost:11211',
            'TIMEOUT': 500,
            'BINARY': True,
            'OPTIONS': {  # Maps to pylibmc "behaviors"
                'tcp_nodelay': True,
                'ketama': True
            }
        }
    }

To use a `memcached local socket connection
<https://code.google.com/p/memcached/wiki/NewConfiguringServer#Unix_Sockets>`_,
set ``LOCATION`` to the path to the file, i.e. ``'/var/run/memcached/memcached.sock'``.

If you want to use the memcached binary protocol, set the ``BINARY`` key's
value to ``True`` as shown above.  ``BINARY`` is ``False`` by default.

If you want to control `pylibmc behaviors
<http://sendapatch.se/projects/pylibmc/behaviors.html>`_, use the
``OPTIONS``.  ``OPTIONS`` is an empty dict by default.

Pylibmc supports `compression
<http://sendapatch.se/projects/pylibmc/misc.html#compression>`_ and the
minimum size (in bytes) of values to compress can be set via the Django
setting ``PYLIBMC_MIN_COMPRESS_LEN``.  The default is ``0``, which is disabled.

Pylibmc 1.3.0 and above allows to configure compression level, which can
be set via the Django setting ``PYLIBMC_COMPRESS_LEVEL``. It accepts the
same values as the Python `zlib <https://docs.python.org/2/library/zlib.html>`_
module. Please note that pylibmc changed the default from ``1`` (``Z_BEST_SPEED``)
to ``-1`` (``Z_DEFAULT_COMPRESSION``) in 1.3.0.

Since 0.6.2 connections are long-living and not closed after each request. It could cause unwanted ``ConnectionErrors``
being raised by libmemcached when connection is broken. dj-pylibmc will make one more attempt
when a request to memcached fails with ConnectionError. If this behavior doesn't fit your needs, it can be disabled
by setting ``DJPYLIBMC_RETRY_ON_BROKEN_CONNECTION`` Django setting to False.


Configuration with Environment Variables
----------------------------------------

Optionally, the memcached connection can be configured with environment
variables (on platforms like Heroku). To do so, declare the following
variables:

* ``MEMCACHE_SERVERS``
* ``MEMCACHE_USERNAME``
* ``MEMCACHE_PASSWORD``


Caching Timouts
---------------
When setting a cache value, memcache allows you to set an expiration for the
value. Commonly, the value is set to a timeout in seconds. However, other
values are allowed including Unix timestamps and 0 for "never expire". The
highest number of seconds is 30 days - more than that, and the value is
treated like a timestamp.

Django instead tries to work with cache timeouts in seconds after the current
time. 0 is treated as 0 seconds, meaning the item should expire immediately.
A timeout of None signals that the item should not expire. There is some
support for memcache-style Unix timestamps as well.

In the distant past (Django 1.3?), a timeout of 0 was converted to the default
timeout.

The current dj-pylibmc behaviour is to pass 0 to the backend, which should
be interpreted as "never expire". Omiting the timeout will get the Django
default.

In the future, dj-pylibmc will adopt the latest Django behaviour.
The safest solution for your own code is to omit the timeout parameter (and
get the default timeout), or set it to a timeout in seconds (less than 30
days). This way, your code will work when the Django behaviour is adopted.
Avoid using a timeout of 0, None, or a negative number.

Testing
-------

Install `tox <http://tox.testrun.org/>`_::

    pip install tox

Run the tests like this::

    tox


Changelog
=========

0.6.4 - 2020-11-30
------------------
- Correctly handles MemcachedError with no retcode attribute
- Adds black formatiing
- Supports Python 3.6 through 3.8

0.6.3 - 2020-10-21
------------------
- Makes retry on ConnectionError
- Drops support of old Python and Django version
- Supports Django 2.2 through 3.1
- Supports Python 3.5 through 3.8

0.6.2 - 2020-10-16
------------------
- Supports Django 1.7 through 3.1
- Supports Python 2.7 through 3.8

0.6.1 - 2015-12-28
------------------
- Supports Django 1.7 through 1.11
- Supports Python 2.7, 3.4, and 3.5

0.6.0 - 2015-04-01
------------------
- Requires pylibmc 1.4.1 or greater
- Supports Django 1.4 through 1.8.
- Supports Python 2.5 through 2.7, and Python 3.3 through 3.4
- In Django 1.6 and higher, when the timeout is omitted, the default
  timeout is used, rather than set to "never expire".



_(Older changes can be found in the full documentation)._