Metacard Versioning

Owned by Keith Wire
Last updated: Nov 02, 2015

Summary

Metacard Versioning is the idea of maintaining a historical record of all changes to a metacard.  Any time any update is made to a metacard, rather than changing the existing metacard, versioning would create a new metacard, mark it as the current/latest version.  Users would then have the ability to see how a particular metacard has changed over time.  All of this must be configurable such that an Administrator can turn this feature off if desired.

Database Impacts

The CatalogProvider would be updated to support 2 new fields, EDITED_BY & STATE.  EDITED_BY would simply be the user or system making the change.  STATE would be an enumeration (ACTIVE, DELETED, ARCHIVED) to identify which instance of a metacard is the "current" or "active" version.  The query logic would have to be updated to only search metacards where STATE == ACTIVE.  The versions themselves would be identified by the database generated timestamp when a metacard is ingested/updated.  

An UpdatePlugin would be implemented to modify the STATE attribute as needed.

Deleting a metacard would not actually delete a metacard but simply mark all versions of the metacard STATE as DELETED.  A after a metacard has been in the deleted state for some time (an administrator configurable time, e.g. 30 days), the DELETED metacards would be permanently removed.

Accessing History

A new query mode (HISTORY) would be introduced to allow a query to ignore the STATE attribute.  Initially this could be limited to ID queries, and upon need could be expanded to support other filters.

An ActionProvider would be implemented to invoke the HISTORY query mode and retrieve the history for a given metacard ID.  The response would be a list of metacards made up of a unique metacard for each of the updates made.

From the UI a diff utility could be provided to the user to show what changed between 2 given versions.  A library like https://github.com/benjamine/jsondiffpatch or https://code.google.com/p/google-diff-match-patch/ may allow this to be easily visualized.  Via this visualization the user should be able to revert history if desired.  I.e. if there are 5 versions, 1 to 5, where 5 is the current version, and the user chooses to revert to version 3, then version 4 and 5 would be marked as DELETED and version 3 would be marked as ACTIVE.

New Capability Summary

  • View History given the ID of a metacard
    • Could be expanded to provide history given any filter (think pub/sub, get all updates since user's last login)
  • Revert Metacards to a previous version
  • Metacards would be "soft-deleted" and users could "recover" them

Candidate Tickets

  • Add EDITED_BY & STATE metacard attributes to support versioning.
  • Update SolrCatalogProvider query logic to only query metacards marked "STATE == ACTIVE".
  • Implement an UpdatePlugin to update the STATE attribute appropriately, and create a new version of the metacard instead of updating the current metacard.
  • Add query mode HISTORY to allow ID searches to retrieve all versions of a metacard.
  • Implement an ActionProvider to retrieve the history of a metacard and to visualize those versions.