Make cache lazy to allow test runners to switch cache backends

[brianjaystanley]

django.core.cache.cache is currently a module-level variable that references an instance of the default cache backend from settings.CACHES. Loading the cache backend into a module-level variable makes it difficult to switch to a different cache backend at runtime. Switching cache backends at runtime would be useful in test runners, in order to be able to test caching-related functionality without populating a production cache. settings.CACHES supports multiple caches, but the only way to use a cache other than the "default" is by calling get_cache, but then only the caller has the reference to the new cache backend while other modules (including the cache-based session backends) will continue to use the default cache backend referenced by django.core.cache.cache.

The patch wraps the cache variable in SimpleLazyObject. This allows doing something like this in a test runner:

cache._wrapped = get_cache('test')

This doesn't break anything in the Django test suite.

[brianjaystanley]

The patch also allows any cache backend loaded through get_cache to register a request_finished signal handler if it needs to. In the original, the signal registration is only available for the default cache, so loading another cache that needs to do cleanup will not register its handler. In the patch, registration will happen later because of the cache being lazy, but that should be fine since no cache backend should need to receive request_finished signals if it was never even loaded.

[Piotr Czachur]

It would be reasonable for Django test runner to switch cache backend (from production to testing one) or add a cache key prefix to default backend.

[Aymeric Augustin]

The argument in favor of this change is:

Switching cache backends at runtime would be useful in test runners, in order to be able to test caching-related functionality without populating a production cache.

Running tests on a production server, with production settings, certainly isn't something we want to encourage. You should use a different settings file, or even better, a clone of your production environment.