Opened 6 months ago
Last modified 6 months ago
#35465 closed New feature
Feature: allow pre-caching and disable-cache — at Version 1
Reported by: | Julien Palard | Owned by: | nobody |
---|---|---|---|
Component: | Core (Cache system) | Version: | 5.0 |
Severity: | Normal | Keywords: | cache |
Cc: | Julien Palard | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
TL;DR: If there was a way to inhibit cache.get()
(making it to always return default
), it would enable to use cases :
- One could implement a pre-caching tool like a simple curl in a crontab.
- One could implement a "disable cache" feature like the one in browsers network panel, but applied server-side.
Longer explanation:
My initial idea is was to prefill the cache (say template fragments) using a cron to guarantee cache hits for humans.
In the current Django, I can't do it: the cron would often just cache hit, doing nothing, and a random human will cache miss and have a slower request.
So I think I need a way to tell "if it's the pre-caching cron, don't try to 'get' from the cache, just compute everything slowly, and fill the cache with fresh data'.
And for this to work I « just need » to replace the real get during the pre-caching step with:
def get(self, key, default=None, version=None): return default
For example, if I have a 15mn cache with a 10mn cron, the cache will never be close to expire, and it would be impossible for a user to cache miss.
Once this implemented, it could be "reused"/"recycled" as a "disable-cache" feature: say for example the Django Debug Toolbar could have a checkbox "disable cache", it would have the strange side effect to populate the cache, but it would work as expected: the presented data would be fresh.
Say we're going this way, it would need for a way to tell "this request is without cache", like a cookie, a query string parameter, or whatever fits in an HTTP request. If there's no concensus on how to flag this "cache disabled" behavior it could be implemented as a dotted path to a function returning a boolean, as SHOW_TOOLBAR_CALLBACK from Django debug toolbar.
There's a "security" catch to be aware of: if it's too easy to disable cache on production servers, like ?cache=no
it could be used to DoS, it probably has to be a tad more secure like by using a secret.
I have not tried to implement it, I'd like to discuss it before, so: does it looks like a good idea? Has it been discussed many times before that I missed maybe?