• 
      

    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.