Opened 42 minutes ago
#37112 assigned Cleanup/optimization
Allow setting `MAX_ENTRIES` in `OPTIONS` of cache backend to `None`
| Reported by: | jodizzle | Owned by: | jodizzle |
|---|---|---|---|
| Component: | Core (Cache system) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | jodizzle | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Relevant previous tickets:
Excerpting from regiov's comment on #32785:
Since I'm erasing the whole cache externally depending on certain conditions, both my TIMEOUT and MAX_ENTRIES can be None, meaning the DELETE statement is never run. However, SELECT count(*) still gets called unnecessarily on every addition to the cache. A simple condition to check if MAX_ENTRIES is not None before counting records would be enough for my use case.
I support the idea of allowing MAX_ENTRIES to be None. Also, while #32785 and regiov's comments are specifically about the database cache backend, it would be more natural to locate this change in `BaseCache` along with the other cache framework settings.
MAX_ENTRIES being None would—for the cache backends that honor it—imply that Django does not cull the cache. Django users would be responsible for their own culling.
This feature would make the caching frameworks more flexible in cases like the one that regiov describes. This feature also feels congruent with the way that it's already possible to set the cache TIMEOUT to be None.
The main disadvantage I see is the possibility that a Django app accidentally sets MAX_ENTRIES to None, and as a consequence the app's cache grows arbitrarily large without the developer noticing. But this feels marginal to me.