Populating settings.CACHES based on settings.CACHE_BACKEND can fail

[Jeremy Dunck]

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 a.py and b.py, where b.py 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):
https://code.djangoproject.com/browser/django/trunk/django/core/cache/__init__.py?rev=16549#L76

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

[Aymeric Augustin]

The main cause of problem is that you're importing django.core.cache in a setting file, namely a.py. 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:
​https://docs.djangoproject.com/en/1.2/ref/settings/#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.