Fixed #16785 -- Documented some of the design decisions of the cache framework.
Thanks jamesp for the draft patch.
This commit is contained in:
parent
9173d2cb74
commit
dd98ccd482
|
@ -307,3 +307,29 @@ Differentiate between GET and POST
|
|||
|
||||
GET and POST are distinct; developers should explicitly use one or the other.
|
||||
The framework should make it easy to distinguish between GET and POST data.
|
||||
|
||||
.. _cache-design-philosophy:
|
||||
|
||||
Cache Framework
|
||||
===============
|
||||
|
||||
The core goals of Django's :doc:`cache framework </topics/cache>` are:
|
||||
|
||||
Less code
|
||||
---------
|
||||
|
||||
A cache should be as fast as possible. Hence, all framework code surrounding
|
||||
the cache backend should be kept to the absolute minimum, especially for
|
||||
``get()`` operations.
|
||||
|
||||
Consistency
|
||||
-----------
|
||||
|
||||
The cache API should provide a consistent interface across the different
|
||||
cache backends.
|
||||
|
||||
Extensibility
|
||||
-------------
|
||||
|
||||
The cache API should be extensible at the application level based on the
|
||||
developer's needs (for example, see :ref:`cache_key_transformation`).
|
||||
|
|
|
@ -39,6 +39,10 @@ Django also works well with "upstream" caches, such as `Squid
|
|||
caches that you don't directly control but to which you can provide hints (via
|
||||
HTTP headers) about which parts of your site should be cached, and how.
|
||||
|
||||
.. seealso::
|
||||
The :ref:`Cache Framework design philosophy <cache-design-philosophy>`
|
||||
explains a few of the design decisions of the framework.
|
||||
|
||||
.. _setting-up-the-cache:
|
||||
|
||||
Setting up the cache
|
||||
|
|
Loading…
Reference in New Issue