Collection version history » History » Revision 5

« Previous | Revision 5/17 (diff) | Next »
Peter Amstutz, 07/11/2018 04:02 PM

Collection version history


Background: desired API features (see #13109, #13494)
  • Get current + previous versions of a collection with a single API call
  • Search all current + previous versions of collections with a single API call
  • Stable small numeric "version number" for each version of a given collection
  • Store all versions in the collection table (much easier to do paging)
  • New database column indicates current version's UUID
  • New database column indicates user-friendly version number (starting at 1) -- can be assigned safely after locking "current" row for update
  • Assign version number to the current version -- this way {uuid,version} can be used as a permanent reference to a specific version
  • Flag "include_past_versions" for "list" API to include old versions (otherwise, filter on current_version_uuid=uuid -- might need to adjust indexes to maintain performance)
  • Flag in site configuration to enable preserving old versions in database
  • Update owner_uuid of all old versions when it changes in the current version
  • A permission link to the current version implies permission to its entire history
  • Prohibit permission links to old versions (should be handled by check "can only make links to things that are visible to you", and not including old versions)
  • Old versions may not be modified except for certain fields which must be synchronized with "current" version changes (owner_uuid, trash_at, delete_at), updating owner_uuid, trash_at, delete_at does not update modified_at (???) so modified_at shows when the version was created
  • Old versions with duplicate "name" does not conflict with (owner_uuid, name) uniqueness constraint
  • The following changes introduce a new version: manifest_text, description (), properties ()

Updated by Peter Amstutz over 4 years ago · 5 revisions