Code of Conduct
Feature Description
Several cache arguments to the caching backend automatically and silently revert to defaults if there's an explicit error in the configuration. I propose that Django should instead complain about the misconfiguration.
Problem
The following cache arguments
TIMEOUT
OPTIONS['MAX_ENTRIES']
OPTIONS['CULL_FREQUENCY']
are integer values that are handled by BaseCache such that non-integer values are ignored and fallback to the default. For example:
- If a Django app didn't set a
TIMEOUT for the caching backend, the cache timeout would be set to 300, the default;
- If a Django app set a
TIMEOUT for the caching backend to 0, the cache timeout would be set to 0, as expected;
- If a Django app somehow set a
TIMEOUT of 'abc', the cache timeout would be set to 300.
My feeling is that the third behavior is wrong. If any of these settings can't be parsed by Django as an integer, Django should throw an error to make it clear to the user that the app is improperly configured. At present, it's possible for a Django application to, for example, silently be using a lower timeout on cache entries than the developer intended.
Request or proposal
proposal
Additional Details
- (I originally ticketed this issue on Trac: https://code.djangoproject.com/ticket/37113. It was suggested that I propose the issue here instead.)
- This behavior does not seem to be documented. The cache arguments section of the documentation mentions the default values, and makes it fairly clear that the settings are for integers, but it doesn't mention that inappropriate values are forced to the defaults.
- This behavior does not seem to be tested in the test suite. If the error swallowing logic is removed, the test suite still passes.
- Per the previous two points: even if this proposal isn't accepted, the current behavior of the caching backend should be documented and tested.
Implementation Suggestions
The implementation should be straightforward: modify the logic in BaseCache.__init__ to not ignore errors like it currently does. At the most basic level, drop the exception handling, e.g., pivot the handling of the timeout from
timeout = params.get("timeout", params.get("TIMEOUT", 300))
if timeout is not None:
try:
timeout = int(timeout)
except (ValueError, TypeError):
timeout = 300
self.default_timeout = timeout
to something like
timeout = params.get("timeout", params.get("TIMEOUT", 300))
if timeout is not None:
timeout = int(timeout)
self.default_timeout = timeout
But it would almost certainly be better to continue to catch bad values, but instead of ignoring, raise a Django exception instead, like ImproperlyConfigured.
Code of Conduct
Feature Description
Several cache arguments to the caching backend automatically and silently revert to defaults if there's an explicit error in the configuration. I propose that Django should instead complain about the misconfiguration.
Problem
The following cache arguments
TIMEOUTOPTIONS['MAX_ENTRIES']OPTIONS['CULL_FREQUENCY']are integer values that are handled by
BaseCachesuch that non-integer values are ignored and fallback to the default. For example:TIMEOUTfor the caching backend, the cache timeout would be set to300, the default;TIMEOUTfor the caching backend to0, the cache timeout would be set to0, as expected;TIMEOUTof'abc', the cache timeout would be set to300.My feeling is that the third behavior is wrong. If any of these settings can't be parsed by Django as an integer, Django should throw an error to make it clear to the user that the app is improperly configured. At present, it's possible for a Django application to, for example, silently be using a lower timeout on cache entries than the developer intended.
Request or proposal
proposal
Additional Details
Implementation Suggestions
The implementation should be straightforward: modify the logic in
BaseCache.__init__to not ignore errors like it currently does. At the most basic level, drop the exception handling, e.g., pivot the handling of the timeout fromto something like
But it would almost certainly be better to continue to catch bad values, but instead of ignoring, raise a Django exception instead, like
ImproperlyConfigured.