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.
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.
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.