[Django] #35465: Feature: allow pre-caching and disable-cache

16 views
Skip to first unread message

Django

unread,
May 17, 2024, 4:28:35 PM5/17/24
to django-...@googlegroups.com
#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.

Django

unread,
May 17, 2024, 4:29:01 PM5/17/24
to django-...@googlegroups.com
#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 | Resolution:
Keywords: cache | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by mdk:

Old description:
New description:
--
Ticket URL: <https://code.djangoproject.com/ticket/35465#comment:1>

Django

unread,
May 21, 2024, 5:43:31 AM5/21/24
to django-...@googlegroups.com
#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 | Resolution:
Keywords: cache | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Sarah Boyce):

Hello!
As this is a new feature request, the recommended path forward is to first
propose the idea on the [https://forum.djangoproject.com/c/internals/5
Django Forum] and see what the community thinks about the suggestion.
You'll reach a much wider audience and likely get extra feedback.
I'll close the ticket for now, but if there is a community agreement for
this, 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
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features].
--
Ticket URL: <https://code.djangoproject.com/ticket/35465#comment:2>

Django

unread,
May 21, 2024, 5:43:47 AM5/21/24
to django-...@googlegroups.com
#35465: Feature: allow pre-caching and disable-cache
-------------------------------------+-------------------------------------
Reporter: mdk | Owner: nobody
Type: New feature | Status: closed
Component: Core (Cache system) | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: cache | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Sarah Boyce):

* resolution: => wontfix
* status: new => closed

--
Ticket URL: <https://code.djangoproject.com/ticket/35465#comment:3>
Reply all
Reply to author
Forward
0 new messages