-
Key: SYSMOAS_-82
-
Status: open
-
Source: Dassault Systemes ( Mr. Tomas Vileiniskis)
-
Summary:
Within ProjectDataVersioningService PIM-level service specifications createCommit service Element deletion rules state the following:
When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted, and any references from other DataIdentity are also removed to maintain data integrity. In addition, for Element Data (KerML), deletion of an Element must also result in deletion of incoming Relationships.
This seems to be model-breaking, especially in cases of ownership-based Relationships (e.g. OwningMembership, FeatureMembership). Example:
Namespace – (OwningMembership Relationship) --> Package packA – (OwningMembership Relationship) --> PortDefinition portA.
When deleting Package packA, according to the rule described, an incoming OwningMembership Relationship should be deleted as well. However, the outgoing OwningMembership Relationship pointing to PortDefinition portA would remain to exist in the model leaving portA floating without any owner (OwningMembership Relationship has no source, it has been deleted).
Simply deleting outgoing Relationships in addition to incoming ones would also not help in this case, as the PortDefinition portA would also remain without any owner in the model.
We need to take a closer look into various Relationship kinds and their semantics in order not to break the model when manipulating via API services.
-
Reported: SystemsModelingAPI 1.0b2 — Thu, 23 May 2024 12:32 GMT
-
Updated: Thu, 23 May 2024 12:33 GMT
SYSMOAS_ — createCommit Element deletion rules are model-breaking
- Key: SYSMOAS_-82
- OMG Task Force: Systems Modeling API and Services (SystemsModelingAPI) 1.0 FTF 2