| Problem in ElementOperations.getRelationships() [message #1730755] |
Thu, 28 April 2016 05:59  |
Eclipse User |
|
|
|
After undoing the creation of a Relationship, the ElementOperations.getRelationships() method still returns the raltionship.
Assume you have a class A and a Requirement R.
Now you add a Satisfy relation r. A call to
ElementOperations.getRelationships(A);
reveals r.
After an undo of this operation a call to
ElementOperations.getRelationships(A);
still reveal r.
Note that r is expectedly not contained at all (neiter in a Resource nor in a Container). It is resloved by the CrossReferenceAdapter. It looks like the CrossReferenceAdapter also returns the references of deleted objects.
I wasn't aware that the crossReferenceAdapter keeps the references of deleted objects so I am a little confused here.
Does this make sense or am I missing something?
Regards,
Thorsten
[Updated on: Thu, 28 April 2016 06:15] by Moderator |
|
|
| Re: Problem in ElementOperations.getRelationships() [message #1730784 is a reply to message #1730755] |
Thu, 28 April 2016 08:57  |
| Eclipse User |
|
|
|
Hi, Thorsten,
It makes sense according to the specific implementation of the
cross-reference adapter.
If your undo is based on applying the ChangeDescription produced by a
ChangeRecorder, then you need to ensure that the ChangeRecorder can
observe (and record) not only the addition of the Satisfy relationship
to the model resource but also the assignment of the references from
that Satisfy to the Requirement and the Class. *If* you first assign
those references and *then* add the Requirement to the model, then the
ChangeRecorder won't have observed those changes and so the
ChangeDescription won't have recorded them and won't be able to undo
them. It will only undo the addition of the Requirement to the model.
The correct procedure is to add the Requirement to the model first, at
which point the ChangeRecorder discovers and starts observing it, and
then set its references.
In general, you want always to add new elements to the model and then
set their various properties afterwards (within the same
transaction/change-recorder, of course).
HTH,
Christian
On 2016-04-28 09:59:02 +0000, Thorsten Schlathölter said:
> After undoing the creation of a Relationship, the
> ElementOperations.getRelationships() method still returns the
> raltionship.
>
> Assume you have a class A and a Requirement R. Now you add a Satisfy
> relation. A call to
>
> ElementOperations.getRelationships(A);
>
> reveals R.
>
> After an undo of this operation a call to
>
> ElementOperations.getRelationships(A);
>
> still reveal R.
>
> Note that R is expectedly not contained at all (neiter in a Resource
> nor in a Container). It is resloved by the CrossReferenceAdapter. It
> looks like the CrossReferenceAdapter also returns the references of
> deleted objects.
>
> I wasn't aware that the crossReferenceAdapter keeps the references of
> deleted objects so I am a little confused here.
> Does this make sense or am I missing something?
>
> Regards,
> Thorsten
|
|
|
| Re: Problem in ElementOperations.getRelationships() [message #1744094 is a reply to message #1730784] |
Thu, 22 September 2016 06:14 |
| Eclipse User |
|
|
|
Just a side remark which is not specific to uml. If we look at this scenario in the context of mapped maps there is a problem lurking.
If we add an EMap.Entry to a respective EMap we actually have to set the key to the entry before putting it into the map. This is necessary because the key's hashCode is used to store the entry in the map.
If we then undo the adding of the entry to the map we end up with a "dangling xref" in the CrossReferenceAdapter. It unexpectedly still finds the entry referencing the key.
So actually one would have to add an empty entry with an AddCommand and set the key and value using respective SetCommands. This works but setting a new key to the entry would require a re-hash
of the entry in the map. In other words if we follow this approach to avoid the dangling xref we are not able to retrieve the value with the key afterwards.
Actually this is expected behaviour as the API contract for Entry.setKey states:
/**
* Sets the key.
* This should only be called by the map implementation,
* since the key of an entry already in the map must be immutable.
* @param key the key.
*/
|
|
|
Powered by
FUDForum. Page generated in 0.08690 seconds
Home