-
Key: SYSMOAS_-121
-
Status: open
-
Source: Model Driven Solutions ( Mr. Cory Casanave)
-
Summary:
Statements about “deleting” data versions does not communicate the intent. DataVersions are immutable and should not be “deleted”. If the DataVersion for the deletion of an identity were to be deleted, there would be no record of the delete, and merge could not work.
In 7.1.2 it is stated: “DataVersion.identity is unique among records listed in commit.versionedData and in Commit.change”
Therefore, there cannot be a conflicting DataVersion for the same identity in the same commit, the deleting DataVersion must remain in the change set and can’t be “deleted”. The delete should not impact any previous commit, so no DataVersions should be deleted. However, the deleting DataVersion must not be in the derived “versionedData” set.
The other consideration is the deletion of incoming references, as documented in SYSMOAS_-82. We suggest those constraints be removed until we have full constraint propagation in the API to ensure model consistency – it is an expensive operation that could break the model.
Based on this issue and in SYSMOAS_-82. Clearer wording should be provided for “3) Deleting data” in table 3. Suggested wording is:
3) Deleting Data - Commit.change should include a DataVersion record with DataVersion.payload not provided, thereby indicating deletion of DataIdentity in the new commit. DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, the DataVersion for that identity shall not be included in the derived versionedData relationship for that commit.
-
Reported: SystemsModelingAPI 1.0b2 — Mon, 3 Feb 2025 21:46 GMT
-
Updated: Wed, 12 Feb 2025 22:04 GMT
SYSMOAS_ — The description of Commit.change-Deleting is not clear
- Key: SYSMOAS_-121
- OMG Task Force: Systems Modeling API and Services (SystemsModelingAPI) 1.0 FTF 2