Opened 7 years ago

Closed 7 years ago

#16488 closed Bug (worksforme)

Populating settings.CACHES based on settings.CACHE_BACKEND can fail

Reported by: Jeremy Dunck Owned by: nobody
Component: Core (Cache system) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I'm fairly sure this will be WONTFIX'd but I wanted to note this failure case in case it helps others.

If django.core.cache is imported before settings finish loading, it is possible that settings.CACHE_BACKEND will not yet be set, so that forward-compatibility patching proceeds incorrectly -- using locmem rather than whatever may have been declared later.

In my case, I ran into this with the fairly-common pattern of 2 settings files and, where imports * from a. A side-effect of importing a was that django.core.cache got imported.

The final config is defined with CACHE_BACKEND = "dummy://", but CACHES ended up with default engine of "locmem://".

Here's the code that patches CACHES from CACHE_BACKEND (if it's there):

Perhaps a better option would be to make the patching lazier...

Change History (1)

comment:1 Changed 7 years ago by Aymeric Augustin

Resolution: worksforme
Status: newclosed

The main cause of problem is that you're importing django.core.cache in a setting file, namely But the whole point of django.core.cache is to reach this line:

cache = get_cache(DEFAULT_CACHE_ALIAS)

Therefore, you need the cache settings!

An additional cause is that some code kicks in to ensure backwards compatibility with Django 1.2, where there was a default cache backend:

At this point, Django doesn't raise an exception, but it emits a visible warning: "settings.CACHE_* is deprecated; use settings.CACHES instead.", which should point users facing the same problem as you in the right direction.

I don't see what else we can do, so indeed, I'll close this ticket.

Note: See TracTickets for help on using tickets.
Back to Top