Arvados

See Collection version history

For some types of collections, particularly things like reference data, it is desirable to keep old versions around if they are updated.

User-facing features¶

• A collection has a current version number, so that the pair (uuid, version_nr) is be enough as a reference to a specific version of a particular collection.
• Whenever a collection get its manifest_text, description, properties or name fields updated, a new version is created (a 'snapshot' of the collection-to-be-changed record is created pointing to the updated, most current version.)
• The user can request a collection via an API call that includes past versions.
• The user can search on collections including past versions.
• Whenever a collection changes owner, uuid, storage classes, replication levels and trashed status, its past versions follow it.
• In order to modify a past version, the user needs to copy it into a new collection.

On workbench¶

• A new 'History' tab show the currently viewed collection position on a list of versions.
• On the 'History' tab, versions have the possibility to be copied to an entirely new collection and also to be copied as the current version (revert feature) on the history
• The collection's main pane show an indication if its the current version or an old one.

System wide configurations¶

• Flag to enable version history retention (OFF by default)

Implementation details¶

• All past versions go on the same collections table (so it's easier to do paging)
• New column current_version_uuid to hold the current version's UUID.
• New column version_number to hold a consecutive integer, starting at 1 for new collections.
• The following fields are synced with their past versions counterparts: replication_*, storage_classes_*, trash_at/delete_at/is_trashed, owner_uuid, uuid (update current_uuid to retain database consistency)
• Old versions with the same name shouldn't conflict with each other or other collections.