Reinstall extension media when the version of the extension changes.

Review Request #5673 — Created April 3, 2014 and submitted

Information

Djblets
master
c1e7873...

Reviewers

Upgrades for extensions which include static media (like javascript or CSS) are
highly annoying, because in addition to installing the package, the user has to
disable the extension, then re-enable it. This change fixes all that.

When we install extension static media, we add a key to the extension settings
dictionary called _extension_media_version. Then, when initializing the
extension class, if the version stored in settings doesn't match the one for
the running code, we'll re-install the media.

This is fine and dandy for the single-threaded devserver, but it's possible
that installing a new extension could cause a bunch of threads/processes to try
to reinstall static media all at once on a production server. I've therefore
created a relatively simple locking mechanism to ensure that only one thread
will be installing media for any given extension at a time.

Testing done:

  • Enabled a new extension and saw the media get installed.
  • Disabled an existing extension and re-enabled it, and saw media get installed.
  • Restarted my devserver and saw that static media versions were checked, but no re-installation occurred.
  • Updated the version of an extension, restarted the devserver, and saw that static media got upgraded.
  • Created a lock contention and saw that initializing the extension waited for the lock to clear.
Description From Last Updated

What happens if RB is scaled across servers, and two handle the same request at the same time? Especially with …

chipx86chipx86

Can we move this to the class definition? Also, I'm not sure we want to key this off on media …

chipx86chipx86

I don't know that this will actually re-fetch from the database. Settings sync won't kick in while we're in a …

chipx86chipx86

If we pull the key out above, we can reuse it here.

chipx86chipx86
chipx86
  1. 
      
  2. djblets/extensions/manager.py (Diff revision 1)
     
     
    Show all issues

    What happens if RB is scaled across servers, and two handle the same request at the same time? Especially with in-extension upgrades.

    Maybe instead of a file-based cache, we just do this with memcached?

    1. Don't we want extension media on all front-end servers?

    2. True, unless we're storing centrally somewhere. Guess my concern was more about the types of updates extensions might do.

  3. djblets/extensions/manager.py (Diff revision 1)
     
     
    Show all issues

    Can we move this to the class definition?

    Also, I'm not sure we want to key this off on media versions. I think we want a more general _installed_version or something, which we'd then use for handling any in-extension upgrading as well.

  4. djblets/extensions/manager.py (Diff revision 1)
     
     
    Show all issues

    I don't know that this will actually re-fetch from the database. Settings sync won't kick in while we're in a loop. I believe we're going to need to re-fetch the extension entry from the database.

  5. djblets/extensions/manager.py (Diff revision 1)
     
     
    Show all issues

    If we pull the key out above, we can reuse it here.

  6. 
      
david
chipx86
  1. Ship It!

  2. 
      
chipx86
  1. Should update the description for the version key.

  2. 
      
david
Review request changed
Status:
Completed
Change Summary:
Pushed to master (c24221f).