使用缓存框架的通用办法是缓存视图结果。django.views.decorators.cache
定义了一个 cache_page
装饰器,它将自动缓存视图的响应:
from django.views.decorators.cache import cache_page
@cache_page(60 * 15)
def my_view(request):
...
cache_page
使用了一个单独的参数:缓存过期时间,以秒为单位。在上面的例子里,my_view()
视图的结果将缓存15分钟。(注意,我们用 60 * 15 这样的方式编写,目的是方便阅读。 60 * 15 将计算为 900,也就是15分钟乘以每分钟60秒。)
cache_page
设置的缓存超时优先于 Cache-Control
头中的 max-age
指令。
和缓存站点一样,对视图缓存,以 URL 为键。如果许多 URL 指向相同的视图,每个 URL 将被单独缓存。继续以 my_view
为例,如果你的 URLconf
是这样的:
urlpatterns = [
path('foo/<int:code>/', my_view),
]
那么 /foo/1/
和 /foo/23/
的请求将被分别缓存,正如你所料。但一旦部分 URL (比如 /foo/23/
)已经被请求,那么随后的请求都将使用缓存。
cache_page
也可以传递可选关键字参数 cache
,它指引装饰器在缓存视图结果时使用特定的缓存(来自 CACHES
设置)。默认情况下,将使用默认缓存,但你可以指定任何你想要的缓存:
@cache_page(60 * 15, cache="special_cache")
def my_view(request):
...
你可以基于每个视图覆盖缓存前缀。cache_page
传递了一个可选关键字参数 key_prefix
,它的工作方式与中间件的 CACHE_MIDDLEWARE_KEY_PREFIX
相同。可以这样使用它:
@cache_page(60 * 15, key_prefix="site1")
def my_view(request):
...
key_prefix
和 cache
参数可能需要被一起指定。key_prefix
参数和 CACHES
下指定的 KEY_PREFIX
将被连接起来。
此外, cache_page
在响应中自动设置 Cache-Control
和 Expires
头, 这会影响 下游缓存.
上一节的例子硬编码了视图被缓存的事实,因为 cache_page
改变了 my_view
函数。这种方法将你的视图和缓存系统耦合起来,这样并不理想。例如,你可能想在其他没有缓存的站点上重用这个视图函数,或者你可能想分发这个视图给那些想使用视图但不想缓存它们的人员。解决这些问题的办法是在 URLconf
中指定视图缓存,而不是视图函数旁边指定。
当你在 URLconf
中使用 cache_page
时,可以这样包装视图函数。这是之前提到的 URLconf
:
urlpatterns = [
path('foo/<int:code>/', my_view),
]
将 my_view
包含在 cache_page
中:
from django.views.decorators.cache import cache_page
urlpatterns = [
path('foo/<int:code>/', cache_page(60 * 15)(my_view)),
]
备案信息: 粤ICP备15087711号-2
Copyright © 2008-2024 啊嘎哇在线工具箱 All Rights.
本站所有资料来源于网络,版权归原作者所有,仅作学习交流使用,如不慎侵犯了您的权利,请联系我们。