id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
37112	Allow setting `MAX_ENTRIES` in `OPTIONS` of cache backend to `None`	jodizzle	jodizzle	"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."	Cleanup/optimization	assigned	Core (Cache system)	dev	Normal			jodizzle	Unreviewed	0	0	0	0	0	0