March 2016 Patch 2

Fixes

• dev and prod Celery workers can now run simultaneously.
• Movement download button is no longer erased by cart-button script. Movements that are locked in the cart now have a red background, rather than light blue.
• All movement serializers now point back to their parent piece, if it exists.
• Tag links now point to search page with the tag entered in the "tag" field.

New

• Added colour coding css defaults for the labels across the site representing piece, movements, etc.
• Added breadcrumb-style navigators to detail views for movements and pieces, making it much easier to navigate within the hierarchies created by composer > piece > movement.
• Tag badges on detail views are now hyper-linked to a search for themselves.

March 2016 Patch 1

Fixes

• Deleting collections does not crash.
• Piece and movement tables sorted properly.
• No added commas in "Clear Cart" modal.
• Individual movements put in piece folder in zipped cart.
• Every level of composer serialization contains the shortened title.
• Fixed small cart bugs.

New

• A management command to clear the cache.
• Application version in footer.

February 2016 Major Release

In February 2016 we deployed a major update to the ELVIS Database. This update included many improvements on the front-end and the back-end.

The overarching goal of this release was to make the ELVIS Database an easier project to develop and support in the future. To this end, many of the changes involved refactoring existing code and standardizing class behaviour. In some cases, entire features were rebuilt at a higher standard of quality.

#Improvements

• Standardized Serializers. All serializer code has been rewritten. In the past, each object serializer would define additional serializers for its nested objects. This approach introduced redundant code that was difficult to maintain. Since the February 2016 Update, the entire application now runs on a single set of serializers which depend on common atomic (or minimal) serializers for their nested objects. If a Composer and Collection both contain a Piece, then both the ComposerSerializer and CollectionSerializer will use the same PieceMinSerializer to serialize the Piece.
• Caching all Serialization Results. It is now possible to cache the results of serialization in a large LRU Redis cache. This technique speeds up the application tremendously. As a Redis cache hit is some 10x faster than retrieving and serializing the object directly from the database. Since the serializers are hierarchical, the FullPieceSerializer can check the cache for the serialization results of its composer, movements, and attachments, etc. Since so many objects within the application are collections of other objects, this offers enormous speedup.
• Standardized Views. Nearly all views have been standardized by subclassing the new ElvisDetailView and ElvisListCreateView classes in views/common.py. It is now much easier to apply common view behaviour and privacy policies. Some have already been implemented, including:
  • Object permissions. On detail views, the permissions of the request.user with regards to the requested object will be checked and synthesized into can_edit and can_view keys (Django does not have a default implementation for object-level permissions).
  • Default HTTP verb behaviour. HTTP verb usage has been improved site-wide, and the default permission checks are implemented in these views. PATCH and DELETE are now used for their intended behaviour (instead of hiding everything in POST requests).
  • List filtering and sorting. Some keys have already been implemented for filtering and sorting the list view query-sets. In the future, list templates can implement buttons to make these features obvious.
• Standardized Common Templates. Most pages on the site have had their templates standardized. A number of new base templates have been created, as well as some new snippets that can be imported. For instance, all detail pages now extend a base_detail.html template. This technique will make it much easier to update and improve all detail/list templates at once in the future.
• Reworked Download Cart Backend. The user's cart is now stored in cached session data, rather than as a table in the database. This technique makes adding, removing and checking items in the cart much faster. The cart is simply a cached dictionary of UUIDs. The cart is dumped to the database when the user logs out, and read into the session when the user logs in.
• Other General Download Improvements:
  • No more file selector page. The page where the objects in the cart where deconstructed into a table of attachments, with check-boxes to select files, has been removed. In it's place is a pop-up "modal" window. When the modal pops-up, the user can select the types of files to download and the desired directory structure of the zip archive.
  • No more download-progress bar page. The progress bar is included in the modal mentioned above. All download activity happens on the cart page now.
  • Directories in zip files. All files produced for user download now have hierarchical directories rooted at composers, and have included metadata for each object. This structure makes it much easier to figure out which file is associated with which object.
• Cart Button Improvements. Cart buttons now receive in_cart data from the back-end, and can use JavaScript to request status updates. Cart buttons draw instantly on all pages and can also be updated on an otherwise static page. The script for requesting a refresh of cart buttons has been updated and made more efficient. In addition, an Add All to Cart button has been added to search results. This button allows users to add all search results to their cart in a single click.
• Site-wide UUID Consistency. Most models have been given unique UUIDs, and these UUIDs are reflected in Solr (rather than creating a UUID each time the document was updated). This technique makes it much easier to refer to specific objects, and eliminate duplication in the solr index. Previously, the only IDs were auto-incrementing integers which required further processing in order to select particular models from the database. The new UUID approach is much simpler.
• File serve improvements. Files are now served by a permission protected view, rather than the Django static viewer.
• All python dependencies updated. In particular:
  • Django 1.8.1 -> Django 1.9.1
  • Rest Framework 3.1.1 -> Rest Framework 3.3.2