#35465: Feature: allow pre-caching and disable-cache
-----------------------------------------------+------------------------
               Reporter:  mdk                  |          Owner:  nobody
                   Type:  New feature          |         Status:  new
              Component:  Core (Cache system)  |        Version:  5.0
               Severity:  Normal               |       Keywords:  cache
           Triage Stage:  Unreviewed           |      Has patch:  0
    Needs documentation:  0                    |    Needs tests:  0
Patch needs improvement:  0                    |  Easy pickings:  0
                  UI/UX:  0                    |
-----------------------------------------------+------------------------
 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?
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35465>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f883dedaf-80e935b7-a38e-4c3e-be0c-953cbe6af7aa-000000%40eu-central-1.amazonses.com.

Reply via email to