Add a cache backend that can forward to other cache backends.
Review Request #6480 — Created Oct. 21, 2014 and submitted
In Django, when you set a cache backend, you're stuck with it. Changing
backends after-the-fact doesn't really work without restarting the
application. This is because the 'cache' variable that gets imported is
an instance of the backend computed when django.core.cache loaded.While we didn't used to have any issues from this in Review Board, some
new imports resulted in the cache backend being computed before we could
set the proper settings.CACHES entries.This change gives us some flexibility by introducing
ForwardingCacheBackend. Projects can set this as the default cache and
then specify the real desired cache backend as another named backend,
and point ForwardingCacheBackend to it. All requests and operations will
go through there.The siteconfig support has been updated to work with this. Nothing
really changes for consumers. Projects not suffering from the early
import problem will get the correct settings automatically, and projects
that do suffer from it will just need to make a change in settings
anyway (since prior to this, that was the only reliable way to set cache
in that situation).While here, I also fixed up the normalization of the class name to not
use deprecated modules.
Wrote a script that would load the current cache, show the backend,
set a new one in siteconfig, apply siteconfig settings, and show the new
backend.Without this new backend, the desired backend wouldn't be set.
With this backend, the desired backend was set, and I could verify that
it was being used for all caching operations.
- Change Summary:
-
Appease Review Bot.
- Commit:
-
6d64e0bf84738360002cf86f0adc7e7bbb047db04c63e576252119aca798482ee7b160de885d1810
-
Tool: PEP8 Style Checker Processed Files: djblets/siteconfig/tests.py djblets/siteconfig/django_settings.py djblets/cache/backend_compat.py djblets/cache/forwarding_backend.py Tool: Pyflakes Processed Files: djblets/siteconfig/tests.py djblets/siteconfig/django_settings.py djblets/cache/backend_compat.py djblets/cache/forwarding_backend.py
- Change Summary:
-
Also make normalization of the memcached module not use the old class path.
- Description:
-
In Django, when you set a cache backend, you're stuck with it. Changing
backends after-the-fact doesn't really work without restarting the application. This is because the 'cache' variable that gets imported is an instance of the backend computed when django.core.cache loaded. While we didn't used to have any issues from this in Review Board, some
new imports resulted in the cache backend being computed before we could set the proper settings.CACHES entries. This change gives us some flexibility by introducing
ForwardingCacheBackend. Projects can set this as the default cache and then specify the real desired cache backend as another named backend, and point ForwardingCacheBackend to it. All requests and operations will go through there. The siteconfig support has been updated to work with this. Nothing
really changes for consumers. Projects not suffering from the early import problem will get the correct settings automatically, and projects that do suffer from it will just need to make a change in settings anyway (since prior to this, that was the only reliable way to set cache in that situation). + + While here, I also fixed up the normalization of the class name to not
+ use deprecated modules. - Commit:
-
4c63e576252119aca798482ee7b160de885d18108c5cf7ec368467710d0a5b27d93f7792841a9bc4
-
Tool: Pyflakes Processed Files: djblets/siteconfig/tests.py djblets/siteconfig/django_settings.py djblets/cache/backend_compat.py djblets/cache/forwarding_backend.py Tool: PEP8 Style Checker Processed Files: djblets/siteconfig/tests.py djblets/siteconfig/django_settings.py djblets/cache/backend_compat.py djblets/cache/forwarding_backend.py