Opened 4 months ago
Closed 4 months ago
#35524 closed New feature (wontfix)
Add possibility to renew {% cache %} templatetag
Reported by: | Petr Dlouhý | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 5.0 |
Severity: | Normal | Keywords: | cache templatetag |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The wider context of my use-case is described at: https://code.djangoproject.com/ticket/5815#comment:17
I have a view which uses templates with {% cache %}
templatetag.
When the cache timeouts it results results into database hammering - multiple requests lacking the cache are hitting DB at the same time.
Erasing the cache with make_template_fragment_key
is not an option either, it results in the same situation.
I would like to be able to renew the state of cached parts of my template without erasing the cache key, but rather just setting the new values.
There are two scenarios in which I could use this functionality to solve my problem:
1) I would create a task/job that will periodically renew the cache on that page.
2) The cache would use staggering - I randomize the cache timeout to reduce number of requests without cache. This unfortunately doesn't work, because the cache key will expire at one time.
I am trying to use the 1) solution - the very easy solution is to modify the cache templatetag code with something like:
class CacheNode(Node): def __init__(self, nodelist, expire_time_var, fragment_name, vary_on, cache_name, renew_cache=False): self.renew_cache = renew_cache ... def render(self, context): ... value = fragment_cache.get(cache_key) if value is None or self.renew_cache value = self.nodelist.render(context) fragment_cache.set(cache_key, value, expire_time) return value ...
Right now I have this custom templatetag, but I am not very happy that I have to copy and maintain a big portion of code from Django.
I think Django should provide some mechanisms to deal with situations like this (and ticket #5815 is supporting this claim).
Hi Petr, I can see why you would want a new feature here.
For cases like this, the recommended path forward is to first propose and discuss the idea with the community and gain consensus on how to push this forward (this might be complex so a third party package may even be a good idea here). To do that, please consider starting a new conversation on the Django Forum, where you'll reach a wider audience and likely get extra feedback.
I'll close the ticket for now, but if there is a community agreement for the feature request, you are welcome to come back to the ticket and point to the forum topic, so we can then re-open it. For more details, please see the documented guidelines for requesting features.
Thanks!