Feature #13109
Updated by Tom Clegg almost 6 years ago
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.
Q: *One possible implementation is copy-on-write where a new copy of the object is made if certain important attributes change (only manifest?). The new collection should have a link to the source that it is cloned from.*
A: When some important attribute changes, before saving it to the database, clone the collection so that it’ll have the same PDH but a different UUID, and this will be treated as an ancestor of the “source” collection. The source collection will then receive the updates, and also get its ancestor field updated with the cloned collection’s UUID.
Q: *Do UUIDs move to new collection? If they don't, it might mess up things like: FUSE mount, Keep Web might*
A: Depending on what we call “new collection”. When an existing collection is getting updated, a “new collection” will be created as a snapshot, keeping its PDH for reference purposes, and getting a new UUID. The original collection record will then be updated, and because of that, it’s PDH will change but its UUID will be the same. FUSE & keep web will continue to work as they’re working nowadays.
Q: *Do we need the ability to lock collections?*
A: To avoid concurrency issues (2 updates at the same time), we might need to wrap the cloning-and-updating operation into a transaction.
Q: *What is the interaction between versions and expiration dates?*
A: Previous versions shouldn’t be expiring before the latest one, so if a collection with trash_at date set gets updated and later on this attribute changes, previous versions should be synced. If this is the case, we might need to add an additional field to link to the “next version” so that we can quickly validate that trash_at can only be updated by the user on the latest version. This would also facilitate back & forth version navigation.
Q: *What does the UI for this look like? Do previous versions get filtered by default?*
A: API-wise we should be filtering the previous versions from listings and also making them unmutable. We could add a new api response field with an ordered list of the previous versions uuids, or if that’s too expensive, a separate endpoint.
Q: *Do all versions get trashed & moved as a group?*
A: For simplicity’s sake, I think we should be treating previous versions as part of the latest collection, we could later on add the new behavior taking into consideration what happens if the version chain is broken because some collections are trashed.