GitLab

The original SDU Storage used

1. sequential version numbers and
2. a validation of the version number during record update. Should an update request refer to a version number less than the current last version, the update request is rejected.

This issue is about recording the difference in behavior between original and current R3 Storage, where

1. version numbers are system generated (timestamps) and
2. no validation of the version number happens. As a consequence all updates will succeed including apparently conflicting, simultaneous updates.

It is important to understand that the request to restore the previous SDU/OSDU validation is a breaking change, which may require adding the version property to the list of required system properties (=change in Data Definition affecting all records).

Thanks to @doniger to help understand this requirement.

Priority

1. Behavior change: prevent record update collisions/conflicts.
2. Usability: the int64 numbers are not user friendly; consider usability in the presentation of the version to end-users.

Required actions:

• Decision whether or not the re-implement the update collision prevention.
  • If yes:
    1. Create a transition plan to support the breaking change;
    2. Usage rules for populating the version number in the create/update requests;
    3. Version number presentation recommendations.
  • If no:
    1. Augment documentation to describe the behavior during update collisions/conflicts and how to detect them.