Opened 17 years ago

Last modified 3 weeks ago

#11379 assigned New feature

MAX_ENTRIES of cache backend should not be required

Reported by: wsorenson Owned by: Skeletor-Pirate
Component: Core (Cache system) Version: dev
Severity: Normal Keywords: max_entries cache
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Not every Django project's cache will want to use a max_entries (this could also apply to timeout).

There should be a simple way to turn off this parameter, such as max_entries=0 / timeout=0.

Change History (5)

comment:1 by Alex Gaynor, 17 years ago

Triage Stage: Unreviewed → Accepted

comment:2 by josh, 17 years ago

Resolution: → duplicate
Status: new → closed

This is a duplicate of issue #11260

comment:3 by Sarah Boyce, 3 months ago

Resolution: duplicate
Severity: → Normal
Status: closed → new
Summary: max_entries should not be required → MAX_ENTRIES of cache backend should not be required
Type: → New feature

#37112 was a duplicate

#11260 suggested doing this to solve a different issue (this issue was wontfixed)

comment:4 by Skeletor-Pirate, 3 weeks ago

Implemented in ​PR.

The PR makes MAX_ENTRIES optional: setting it to None (instead of an int) disables cache culling entirely, while TIMEOUT=None already disables expiry. MAX_ENTRIES=0 keeps its current "empty cache" behavior, and MAX_ENTRIES must remain positive when set, so no existing configs change behavior. Docs and a release note are included.
The [url PR] form is the part Django's checker looks for; the rest is for human reviewers.

Version 0, edited 3 weeks ago by Skeletor-Pirate (next)

comment:5 by Skeletor-Pirate, 3 weeks ago

Has patch: set
Owner: changed from nobody to Skeletor-Pirate
Status: new → assigned
Note: See TracTickets for help on using tickets.
Back to Top