Home » Modeling » EMF » [EMF Transaction] EObject removed from ResourceSet has always TransactionChangeRecorder as Adapter
| |
| Re: [EMF Transaction] EObject removed from ResourceSet has always TransactionChangeRecorder as Adapt [message #1430546 is a reply to message #1430333] |
Wed, 24 September 2014 13:49   |
|
Hi, Felix, Esteban,
It's an interesting case, the rollback of the first attachment of a new
EObject. However, I'm not sure that it's really so different from any
other case of detaching an element from the content forest of a
resource set.
It's clear that the intention of the transaction that was rolled back
was to add this new EObject into the context of the particular editing
domain. It would be strange, then, for the application in question to
try to use that EObject in any other domain. Why would it? Other
domains would work with their own copies of all the resources and
objects involved.
I wouldn't recommend trying to make the editing domain treat this case
of detachment from the resource set differently from other cases. An
object that is intended for manipulation in a TED should only be
manipulated in transactions on the TED, whether it is attached or not,
and even before it is attached and therefore before it has the change
recorder in the first place.
Hope that makes sense.
Christian
On 2014-09-24 09:03:56 +0000, Felix Dorner said:
> Hi Esteban,
>
> I think you're hit by something that's documented in EMF Transaction
> doc under "Working with Transactional Editing Domains". Once an object
> belongs to a TED, it will be in that TED until you detach it manually
> with TransactionUtil.disconnectFromEditingDomain(). Now your case is
> interesting, because the add() gets rolled back instantly, so maybe the
> object should have never been part of the domain, or at least EMFT
> should remove its adapters during the rollback?
>
> Felix
|
|
|
| Re: [EMF Transaction] EObject removed from ResourceSet has always TransactionChangeRecorder as Adapt [message #1430637 is a reply to message #1430546] |
Wed, 24 September 2014 15:40 |
 Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi Felix, Christian,
Thanks for your answer.
Le 24/09/2014 15:49, Christian W. Damus a écrit :
> Hi, Felix, Esteban,
>
> It's an interesting case, the rollback of the first attachment of a new
> EObject. However, I'm not sure that it's really so different from any
> other case of detaching an element from the content forest of a resource
> set.
>
> It's clear that the intention of the transaction that was rolled back
> was to add this new EObject into the context of the particular editing
> domain. It would be strange, then, for the application in question to
> try to use that EObject in any other domain. Why would it? Other
> domains would work with their own copies of all the resources and
> objects involved.
>
> I wouldn't recommend trying to make the editing domain treat this case
> of detachment from the resource set differently from other cases. An
> object that is intended for manipulation in a TED should only be
> manipulated in transactions on the TED, whether it is attached or not,
> and even before it is attached and therefore before it has the change
> recorder in the first place.
>
> Hope that makes sense.
>
> Christian
>
>
> On 2014-09-24 09:03:56 +0000, Felix Dorner said:
>
>> Hi Esteban,
>>
>> I think you're hit by something that's documented in EMF Transaction
>> doc under "Working with Transactional Editing Domains". Once an object
>> belongs to a TED, it will be in that TED until you detach it manually
>> with TransactionUtil.disconnectFromEditingDomain(). Now your case is
>> interesting, because the add() gets rolled back instantly, so maybe
>> the object should have never been part of the domain, or at least EMFT
>> should remove its adapters during the rollback?
>>
>> Felix
>
>
--
Esteban Dugueperoux - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
Goto Forum:
Current Time: Tue Apr 16 19:33:57 GMT 2024
Powered by FUDForum. Page generated in 0.05502 seconds |
] 
Search
Help
Register
Login
Home
