Opened 15 years ago
Closed 15 years ago
#12536 closed (invalid)
Issue with usage of @vary_on_cookie decorator with URLconf based cache_page usage
Reported by: | Justin | Owned by: | nobody |
---|---|---|---|
Component: | Core (Cache system) | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
For several months, we have been caching views using the URLconf
method (urls.py). An entry from urls.py is below as an example:
url(r'^(?P<path>.*)/content/(?P<id>[-\w]+)/$$', cache_page(hierarchies.views.category_content_detail, CACHE_TIMEOUT),name='category_content_detail'),
Recently, we had a need to add variance of cache based on cookie value
to support some personalization features. After reading the django
docs, it seemed easy enough to add the @vary_on_cookie decorator to
appropriate views.
@vary_on_cookie def category_content_detail(request, path, id): .. ..
What I've noticed, is that since adding this vary decorator, the page
is no longer caching, as seen by monitoring logs and seeing many
backend processes firing which normally do not fire when the page is
cached.
Any ideas on why I'd see this behavior? My browser is setting the
cookie value appropriately, as I've monitored in Firebug, but I'm just
not seeing any sort of caching taking place. Upon removing the
vary_on_cookie decorator, caching returns to normal.
What I have noticed in testing is this. If I go back to a pure per-view cache setup:
@vary_on_cookie @cache_page(60 * 15) def category_content_detail(request, path, id):
Is there a way to use vary_on_cookie with the URLconf like setup? I
like the flexibility of the URLConf method and but also need the vary
features.
I've also attempted to use the patch_vary_headers function in the views per the docs, with the same results (no caching taking place).
Reference:
http://docs.djangoproject.com/en/dev/topics/cache/#specifying-per-view-cache-in-the-urlconf/
is not the same as
You mention that the first approach works. However, your URLConf view is effectively doing the second.