Opened 13 years ago

Closed 12 years ago

#16006 closed Cleanup/optimization (wontfix)

Make cache lazy to allow test runners to switch cache backends

Reported by: brianjaystanley Owned by: nobody
Component: Core (Cache system) Version: 1.3
Severity: Normal Keywords:
Cc: zimnyx@…, brianjaystanley Triage Stage: Design decision needed
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

lazycache.diff (1.5 KB ) - added by brianjaystanley 13 years ago.

Download all attachments as: .zip

Change History (6)

by brianjaystanley, 13 years ago

Attachment: lazycache.diff added

comment:1 by brianjaystanley, 13 years ago

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.

comment:2 by Aymeric Augustin, 13 years ago

Needs documentation: set
Needs tests: set
Triage Stage: UnreviewedDesign decision needed

comment:3 by Piotr Czachur, 13 years ago

Cc: zimnyx@… added
UI/UX: unset

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.

comment:4 by brianjaystanley, 13 years ago

Cc: brianjaystanley added

comment:5 by Aymeric Augustin, 12 years ago

Resolution: wontfix
Status: newclosed

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.

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