Eclipse Community Forums: UML2 » Problem in ElementOperations.getRelationships()

Help

Home

Home » Modeling » UML2 » Problem in ElementOperations.getRelationships()

Show: Today's Messages :: Show Polls :: Message Navigator

Problem in ElementOperations.getRelationships() [message #1730755]

Thu, 28 April 2016 09:59

Thorsten Schlathölter

Messages: 309
Registered: February 2012
Location: Düsseldorf

Senior Member

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 10:15]

Report message to a moderator

Re: Problem in ElementOperations.getRelationships() [message #1730784 is a reply to message #1730755]

Thu, 28 April 2016 12:57

Christian Damus

Messages: 1221
Registered: July 2009
Location: Canada

Senior Member

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

Report message to a moderator

Re: Problem in ElementOperations.getRelationships() [message #1744094 is a reply to message #1730784]

Thu, 22 September 2016 10:14

Thorsten Schlathölter

Messages: 309
Registered: February 2012
Location: Düsseldorf

Senior Member

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.
*/

Report message to a moderator

Previous Topic:	news.eclipse.org is shutting down.
Next Topic:	Dangling references when creating profile

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Dec 02 23:09:02 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter