Home » Modeling » EMF » Unexpected interaction between UML Association#ownedEnds and DeleteCommand - AssocTest.java (1/1)
|
| Re: Unexpected interaction between UML Association#ownedEnds and DeleteCommand - AssocTest.java (1/1 [message #522926 is a reply to message #522688] |
Wed, 24 March 2010 14:30   |
|
Hi, Volker,
You would need something more like GMF's DestroyCommand, which
disconnects references from the "destroyed" object back to the model.
It was invented for just such a scenario as thes.
Indeed, I think that the UML2 API's Element::destroy() operation does
something similar, and in addition deletes applied stereotypes (very
important!). You might give that a try, perhaps in a ChangeCommand (the
UML2 implementation, not EMF; the former I think has some UML-specific
smarts with respect to subset/superset management that the latter
naturally does not). UML2 may also provide a DestroyCommand, or a
DeleteCommand that does the an element destroy.
In general, I think it wise to use UML2's destroy API for element
deletion, to ensure model integrity, especially for stereotypes and
constructs like the Type::associations derivation.
HTH,
Christian
On 23/03/10 11:15 AM, Volker Stolz wrote:
> (F'up set)
>
> Dear all, the attach small JUnit4 test for the Eclipse Modeling Tools
> 20100218-1602 triggers the 1 1/2 assertions at the bottom of the file.
>
> My interpretation:
> The problem is that the DeleteCommand removes the association from the
> model, but since the association has still the type 'a1' pointing "into"
> the model, a1.getAssociations() still includes the just deleted
> association.
>
> Am I missing some special EMF initialisation that prevents this change
> from being tracked? Is this expected behaviour? If yes, what is the
> suggested way of "traversing" an association (and similar cases) and
> removing/unsetting the corresponding values?
>
> For good measure, even EcoreUtil.remove(assoc) has the same behaviour.
>
> The test case exercises both a "plain" UML/EMF code-path using setters,
> and an alternative using EMF commands.
>
> Cheers,
> Volker
>
|
|
|
| Re: Unexpected interaction between UML Association#ownedEnds and DeleteCommand - AssocTest.java (1/1 [message #522939 is a reply to message #522926] |
Wed, 24 March 2010 15:02 |
 Volker Stolz
Messages: 63
Registered: July 2009 |
Member |
|
|
On 24.03.10 15:30, Christian W. Damus wrote:
> You would need something more like GMF's DestroyCommand, which
> disconnects references from the "destroyed" object back to the model.
> It was invented for just such a scenario as thes.
>
> Indeed, I think that the UML2 API's Element::destroy() operation
> does something similar, and in addition deletes applied stereotypes
> (very important!).
>
> In general, I think it wise to use UML2's destroy API for element
> deletion, to ensure model integrity, especially for stereotypes and
> constructs like the Type::associations derivation.
Hi Christian, thanks for your assessment. I quickly tried putting
assoc.destroy() in a UML ChangeCommand::run() -- same result.
There doesn't seem to be any special Delete/DestroyCommand in UML, in
fact the code I tried was lifted from the DestroyElementAction in the
UML editor.
Cheers,
Volker
|
|
|
| Re: Unexpected interaction between UML Association#ownedEnds and DeleteCommand - AssocTest.java (1/1 [message #523099 is a reply to message #522939] |
Thu, 25 March 2010 05:18 |
|
Hi, Volker,
I'm sorry that it has taken me so long to realize this, but I think I may know what the problem is. The UML2 API uses a CacheAdapter for performance of calculation of derived properties. One of its services is inverse-referencing (via ECrossReferenceAdapter). This is used to find the Associations that have an end typed by your Classifier.
When you delete your association, the CacheAdapter is still attached to it and therefore remembers the link to your classifier. The remedy is to clear the eAdapters() list of the association and all of its contained elements. Although, I thought the Element::destroy() method did this, already.
Anyhow, it's an important point to remember: whenever you need to really dispose of any EObject, you must clear its adapters to ensure that nothing retains references to it and it may be collected. This is what a resource does to all of its contents when it is unloaded. It's particularly vital with UML elements because they always have the CacheAdapter, and it's a singleton! Famous source ofemory leaks...
HTH,
Christian
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 03:38:47 GMT 2024
Powered by FUDForum. Page generated in 0.02546 seconds |
] 
Search
Help
Register
Login
Home
