Transition to CACHES and away from CACHE_BACKEND.

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

Review Board
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. 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 files and to
generate new ones with CACHES instead.
We're actually running this code now on 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.
  1. Ship It!
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-1.7.x (c1c3b78)