Transition to CACHES and away from CACHE_BACKEND.

Review Request #3581 — Created Nov. 29, 2012 and submitted — Latest diff uploaded

Information

Review Board
release-1.7.x

Reviewers

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.