v2.3.1

CHANGELOG.rst

@@ -1,6 +1,11 @@
 What’s new in django-cachalot?
 ==============================
 
+2.3.1
+-----
+
+- Added support for Django 3.1, including the new, native JSONField
+
 2.3.0
 -----
 

CONTRIBUTING.rst

@@ -4,3 +4,20 @@ We appreciate any support in improvements to this system
 in performance, erasing dependency errors, or in killing bugs.
 
 When you start a PR or issue, please follow the layout provided.
+
+To start developing, install the requirements
+and run the tests via tox.
+
+Make sure you have the following services:
+
+* Memcached
+* Redis
+* PostgreSQL
+* MySQL
+
+For setup:
+
+#. Install: ``pip install -r requirements/hacking.txt``
+#. For PostgreSQL: ``CREATE ROLE cachalot LOGIN SUPERUSER;``
+#. Run: ``tox --current-env`` to run the test suite on your current Python version.
+#. You can also run specific databases and Django versions: ``tox -e py38-django3.1-postgresql-redis``

README.rst

@@ -10,6 +10,9 @@ Documentation: http://django-cachalot.readthedocs.io
 .. image:: http://img.shields.io/pypi/v/django-cachalot.svg?style=flat-square&maxAge=3600
    :target: https://pypi.python.org/pypi/django-cachalot
 
+.. image:: https://img.shields.io/pypi/pyversions/django-cachalot
+    :target: https://django-cachalot.readthedocs.io/en/latest/
+
 .. image:: https://travis-ci.com/noripyt/django-cachalot.svg?branch=master
    :target: https://travis-ci.com/noripyt/django-cachalot
 
@@ -36,7 +39,7 @@ Table of Contents:
 Quickstart
 ----------
 
-Cachalot officially supports Python 3.5-3.8 and Django 2.0-2.2, 3.0 with the databases PostgreSQL, SQLite, and MySQL.
+Cachalot officially supports Python 3.5-3.8 and Django 2.0-2.2, 3.0-3.1 with the databases PostgreSQL, SQLite, and MySQL.
 
 Usage
 -----
@@ -73,6 +76,7 @@ For setup:
 #. Install: ``pip install -r requirements/hacking.txt``
 #. For PostgreSQL: ``CREATE ROLE cachalot LOGIN SUPERUSER;``
 #. Run: ``tox --current-env`` to run the test suite on your current Python version.
+#. You can also run specific databases and Django versions: ``tox -e py38-django3.1-postgresql-redis``
 
 Benchmark
 ---------
@@ -98,7 +102,8 @@ There are three main third party caches: cachalot, cache-machine, and cache-ops.
 TL;DR Use cachalot for cold or modified <50 times per seconds (Most people should stick with only cachalot since you
 most likely won't need to scale to the point of needing cache-machine added to the bowl). If you're an enterprise that
 already has huge statistics, then mixing cold caches for cachalot and your hot caches with cache-machine is the best
-mix.
+mix. However, when performing joins with ``select_related`` and ``prefetch_related``, you can
+get a nearly 100x speed up for your initial deployment.
 
 Recall, cachalot caches THE ENTIRE TABLE. That's where its inefficiency stems from: if you keep updating the records,
 then the cachalot constantly invalidates the table and re-caches. Luckily caching is very efficient, it's just the cache

cachalot/__init__.py

@@ -1,4 +1,4 @@
-VERSION = (2, 3, 0)
+VERSION = (2, 3, 1)
 __version__ = '.'.join(map(str, VERSION))
 
 default_app_config = 'cachalot.apps.CachalotConfig'

docs/index.rst

@@ -67,7 +67,8 @@ There are three main third party caches: cachalot, cache-machine, and cache-ops.
 TL;DR Use cachalot for cold or modified <50 times per seconds (Most people should stick with only cachalot since you
 most likely won't need to scale to the point of needing cache-machine added to the bowl). If you're an enterprise that
 already has huge statistics, then mixing cold caches for cachalot and your hot caches with cache-machine is the best
-mix.
+mix. However, when performing joins with select_related and prefetch_related, you can
+get a nearly 100x speed up for your initial deployment.
 
 Recall, cachalot caches THE ENTIRE TABLE. That's where its inefficiency stems from: if you keep updating the records,
 then the cachalot constantly invalidates the table and re-caches. Luckily caching is very efficient, it's just the cache

docs/introduction.rst

@@ -13,7 +13,8 @@ That’s because every possible SQL query on the project ends up being cached.
 
 Django-cachalot is especially efficient in the Django administration website
 since it’s unfortunately badly optimised (use foreign keys in ``list_editable``
-if you need to be convinced).
+if you need to be convinced). One of the best suited is ``select_related`` and
+``prefetch_related`` operations.
 
 However, it’s not suited for projects where there is **a high number
 of modifications per second** on each table, like a social network with

docs/quickstart.rst

@@ -4,7 +4,7 @@ Quick start
 Requirements
 ............
 
-- Django 2.0-2.2, or 3.0
+- Django 2.0-2.2, 3.0-3.1
 - Python 3.5-3.8
 - a cache configured as ``'default'`` with one of these backends:
 

setup.py

@@ -30,8 +30,8 @@
         'Framework :: Django :: 2.1',
         'Framework :: Django :: 2.2',
         'Framework :: Django :: 3.0',
+        'Framework :: Django :: 3.1',
         'Programming Language :: Python :: 3',
-        'Programming Language :: Python :: 3.4',
         'Programming Language :: Python :: 3.5',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',