Transition to CACHES and away from CACHE_BACKEND.
Review Request #3581 — Created Nov. 29, 2012 and submitted
Transition to CACHES and away from CACHE_BACKEND. Django 1.4 introduced CACHES and deprecated CACHE_BACKEND. Aside from an annoying warning, this didn't really impact us for the most part, but it turns out that versioned static media lookups dumps information in the cache mapping a file path to a hashed filename. That causes media breakages on upgrade, as pages will still point to the old files. That logic can be overridden by introducing a 'staticfiles' cache, which a previous change attempted. It didn't work, though, for a few reasons. The main one being that the static media storage code loaded the caches before we had a chance to set our own. Now we're moving entirely onto CACHES. settings.py sets a default CACHES with local memory caching (for dev environments). settings_local then can override it. And then, once we've loaded that, we stick a staticfiles cache in there. This happens during settings loading, so we know it'll get in before the static storage code. rb-site has been updated to upgrade settings_local.py files and to generate new ones with CACHES instead.
We're actually running this code now on reviews.reviewboard.org. It consistently reproduced the problem. I'd tweak one little thing in a .less file and the pages wouldn't update to the new file unless I cleared memcached or restarted Apache. After this change, any site upgrade followed by a reload (which is always recommended) resulted in updates. Tested upgrading existing sites and creating a site. Worked fine.