[Django] #37112: Allow setting `MAX_ENTRIES` in `OPTIONS` of cache backend to `None`

3 views
Skip to first unread message

Django

unread,
May 19, 2026, 6:49:53 PM (2 days ago) May 19
to django-...@googlegroups.com
#37112: Allow setting `MAX_ENTRIES` in `OPTIONS` of cache backend to `None`
------------------------------------------------+--------------------------
Reporter: jodizzle | Owner: jodizzle
Type: Cleanup/optimization | Status: assigned
Component: Core (Cache system) | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+--------------------------
Relevant previous tickets:
- #32785
- #11379 (though the history on this is a little confusing to follow)

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
[https://github.com/django/django/blob/3e4e0db66961a48a080ff3ff91f6c0d954261366/django/core/cache/backends/base.py#L61
`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.
--
Ticket URL: <https://code.djangoproject.com/ticket/37112>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
May 20, 2026, 11:03:46 AM (23 hours ago) May 20
to django-...@googlegroups.com
#37112: Allow setting `MAX_ENTRIES` in `OPTIONS` of cache backend to `None`
-------------------------------------+-------------------------------------
Reporter: jodizzle | Owner: jodizzle
Type: New feature | Status: closed
Component: Core (Cache system) | Version: dev
Severity: Normal | Resolution: duplicate
Keywords: | 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: => duplicate
* status: assigned => closed
* type: Cleanup/optimization => New feature

Comment:

Thank you, reopened https://code.djangoproject.com/ticket/11379
--
Ticket URL: <https://code.djangoproject.com/ticket/37112#comment:1>
Reply all
Reply to author
Forward
0 new messages