Made two small clarifications to docs/cache.txt. Thanks, Paul B.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@2331 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
a10e8153f3
commit
165a4e7809
|
@ -5,7 +5,7 @@ Django's cache framework
|
|||
So, you got slashdotted_. Now what?
|
||||
|
||||
Django's cache framework gives you three methods of caching dynamic pages in
|
||||
memory or in a database. You can cache the output of entire pages, you can
|
||||
memory or in a database. You can cache the output of specific views, you can
|
||||
cache only the pieces that are difficult to produce, or you can cache your
|
||||
entire site.
|
||||
|
||||
|
@ -122,7 +122,7 @@ See the `middleware documentation`_ for more on middleware.
|
|||
|
||||
.. _`middleware documentation`: http://www.djangoproject.com/documentation/middleware/
|
||||
|
||||
The per-page cache
|
||||
The per-view cache
|
||||
==================
|
||||
|
||||
A more granular way to use the caching framework is by caching the output of
|
||||
|
@ -152,8 +152,8 @@ The low-level cache API
|
|||
|
||||
Sometimes, however, caching an entire rendered page doesn't gain you very much.
|
||||
For example, you may find it's only necessary to cache the result of an
|
||||
intensive database. In cases like this, you can use the low-level cache API to
|
||||
store objects in the cache with any level of granularity you like.
|
||||
intensive database query. In cases like this, you can use the low-level cache
|
||||
API to store objects in the cache with any level of granularity you like.
|
||||
|
||||
The cache API is simple::
|
||||
|
||||
|
|
Loading…
Reference in New Issue