Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Geert Bellekens on March 22, 2018, 08:44:58 pm
-
We recently added version control to one of our model in order to share it in a controlled fashion with other models.
The source model is a BPMN model that uses a lot of tagged value references (i.e. MessageRef)
After a user had checked out a package containing messages that were referenced by MessageRef tagged values, those tagged values where emptied, effectively loosing the reference to the message object.
Doing a getlatest on the process package re-instates the tagged value.
This is of course a SERIOUS issue as it slowly destroys our model.
I tried playing with the settings, but nothing seemed to work.
Steps to Reproduce:
packageA
MessageA
packageB
ProcessB with messageFlow containing tagged value MessageRef referencing MessageA
- Version control both packageA as PackageB and check-in both packages.
- Do a getLatest on packageA
- Notice that the messageRef tagged value has been cleared.
Reported and hoping for a quick solution as this is destroying our BPMN model
Geert
-
Did some more digging and the behavior is quite random for different tagged values depending on the object they are defined on:
- Object tagged values => OK
- Attribute tagged values => NOK: emptied
- Connector tagged values => NOK: emptied
- Connector role tagged values => OK
- Operation tagged values => NOK: emptied
- Parameter tagged values => OK
Now trying to figure out how to temporarily work around this problem.
Geert
-
Even more digging reveals that the problem only occurs when doing a GetLatest or an Undo checkout.
A simple checkout (even if the local file is not the latest) does not cause the problem.
That is slightly better news as we can (temporarily) ban getLatest or Undo checkout.
Since the bug seems to be related to the xmi import process, I'm curious where else this problem occurs.
(XMI import, Reusable Assets,...)
Geert
-
After almost a year I bumped into this issue again.
We lost a whole bunch of data because of this bug, and I had to spend the better part of a day to restore it from the backup. >:(
Unfortunately there still isn't a fix available.
I devised a temporary workaround to avoid this problem
Two triggers (one for t_attributeTag, one for t_connectorTag, we don't use operationTags, so I didn't need one for that table)
These triggers avoid emptying a tagged value that previously had a GUID as value.
--CREATE
--ALTER
TRIGGER trgAttributeTagClear
ON t_attributeTag AFTER UPDATE
AS
set nocount on
update atv set atv.Value = d.value
from t_attributetag atv
inner join inserted i on atv.ea_guid = i.ea_guid
inner join deleted d on atv.ea_guid = d.ea_guid
where i.VALUE is null
and d.VALUE like '{________-____-____-____-____________}'
--CREATE
--ALTER
TRIGGER trgConnectorTagClear
ON t_connectorTag AFTER UPDATE
AS
set nocount on
update ctv set ctv.Value = d.value
from t_connectorTag ctv
inner join inserted i on ctv.ea_guid = i.ea_guid
inner join deleted d on ctv.ea_guid = d.ea_guid
where i.VALUE is null
and d.VALUE like '{________-____-____-____-____________}'
Geert