Home » Modeling » EMF » [EMF Transaction] Transaction.getChangeDescription()
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1611838 is a reply to message #1611762] |
Wed, 11 February 2015 16:45   |
|
Hi, Esteban,
After the transaction has committed (for example, in a post-commit
listener), all of the changes made by that transaction, including
triggers, should be included. Otherwise it could never be properly
rolled back or undone. Even non-EMF changes can be included by
triggers that use commands to effect changes to stuff outside of the
model.
You may find that changes made by triggers are buried in some kind of
crazy nested composite change description structure ...
HTH,
Christian
On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
> Hi EMF Community,
>
> In our EMF Transaction based application, we need to know which objects
> have been changed/added/removed after a transaction commit. We have
> seen Transaction.getChangeDescription() API can be used for this but
> changes of precommits, i.e. ResourceSetListener, are not included. This
> is a know issue or i'm confused?
>
> Best Regards.
|
|
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1614804 is a reply to message #1611838] |
Fri, 13 February 2015 14:07 |
 Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Indeed I was lost in transaction :)
As in postcommit Transaction.getChangeDescription() return always null,
I have plugged a ValidateEditSupport to keep a reference to this
ChangeDescription on call to ValidateEditSupport.finalizeForCommit()
method.
After a little analysis, I reproduce my issue when I have 2 resources in
my ResourceSet and that initial command add an object in the first
resource and the precommit in the second resource. I have attached a
test case to reproduce.
Best Regards.
Le 11/02/2015 17:45, Christian W. Damus a écrit :
> Hi, Esteban,
>
> After the transaction has committed (for example, in a post-commit
> listener), all of the changes made by that transaction, including
> triggers, should be included. Otherwise it could never be properly
> rolled back or undone. Even non-EMF changes can be included by triggers
> that use commands to effect changes to stuff outside of the model.
>
> You may find that changes made by triggers are buried in some kind of
> crazy nested composite change description structure ...
>
> HTH,
>
> Christian
>
>
> On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
>
>> Hi EMF Community,
>>
>> In our EMF Transaction based application, we need to know which
>> objects have been changed/added/removed after a transaction commit. We
>> have seen Transaction.getChangeDescription() API can be used for this
>> but changes of precommits, i.e. ResourceSetListener, are not included.
>> This is a know issue or i'm confused?
>>
>> Best Regards.
>
>
--
Esteban Dugueperoux - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1619058 is a reply to message #1614804] |
Mon, 16 February 2015 09:56 |
Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have updated my tests and my analysis, when the main command and the
one from precommit add a EClass on the same EPackage
ChangeDescription.getObjectsToDetach() return both EClasses. In opposite
if precommit add its EClass to another EPackage,
ChangeDescription.getObjectsToDetach() returns only the added EClass
from the main command.
In both cases, the ChangeDescription returned by the Transaction is a
EMFT CompositeChangeDescription composed of an EMF ChangeDescriptionImpl
followed by a EMFT CommandChangeDescription. This last manage the undo
for precommit but give no information when using its accessor
getObjectChanges()/getObjectsToDetach()/getObjectsToAttach(). It's too
bad to not have its information because recompute them in postcommit
from the list of notifications can be costly. If don't understand why we
have this CommandChangeDescription and the TriggerCommandTransaction
which prevent us to use ChangeDescription accessors. Would it be
possible to have these accessors usable in EMF Transaction use case?
Cheers.
Le 13/02/2015 15:07, Esteban Dugueperoux a écrit :
> Hi Christian,
>
> Indeed I was lost in transaction :)
> As in postcommit Transaction.getChangeDescription() return always null,
> I have plugged a ValidateEditSupport to keep a reference to this
> ChangeDescription on call to ValidateEditSupport.finalizeForCommit()
> method.
>
> After a little analysis, I reproduce my issue when I have 2 resources in
> my ResourceSet and that initial command add an object in the first
> resource and the precommit in the second resource. I have attached a
> test case to reproduce.
>
> Best Regards.
>
> Le 11/02/2015 17:45, Christian W. Damus a écrit :
>> Hi, Esteban,
>>
>> After the transaction has committed (for example, in a post-commit
>> listener), all of the changes made by that transaction, including
>> triggers, should be included. Otherwise it could never be properly
>> rolled back or undone. Even non-EMF changes can be included by triggers
>> that use commands to effect changes to stuff outside of the model.
>>
>> You may find that changes made by triggers are buried in some kind of
>> crazy nested composite change description structure ...
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
>>
>>> Hi EMF Community,
>>>
>>> In our EMF Transaction based application, we need to know which
>>> objects have been changed/added/removed after a transaction commit. We
>>> have seen Transaction.getChangeDescription() API can be used for this
>>> but changes of precommits, i.e. ResourceSetListener, are not included.
>>> This is a know issue or i'm confused?
>>>
>>> Best Regards.
>>
>>
>
>
>
--
Esteban Dugueperoux - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1620861 is a reply to message #1619058] |
Tue, 17 February 2015 13:39 |
|
Hi, Esteban,
Thanks for digging deeper. Indeed, it would seem that the
CommandChangeDescription is not quite fulfilling the contract of the
interface that it implements if it does, indeed, encapsulate EMF
changes. It wasn't anticipated that clients would actually want to
access this information; the change descriptions were only really
intended to support roll-back and undo/redo, which is an internal
concern.
I have no doubt that it would be possible to publish those EMF changes
in the CommandChangeDescription. You may want to work up a patch
contribution in Bugzilla.
Cheers,
Christian
On 2015-02-16 09:56:52 +0000, Esteban Dugueperoux said:
> Hi Christian,
>
> I have updated my tests and my analysis, when the main command and the
> one from precommit add a EClass on the same EPackage
> ChangeDescription.getObjectsToDetach() return both EClasses. In opposite
> if precommit add its EClass to another EPackage,
> ChangeDescription.getObjectsToDetach() returns only the added EClass
> from the main command.
>
> In both cases, the ChangeDescription returned by the Transaction is a
> EMFT CompositeChangeDescription composed of an EMF ChangeDescriptionImpl
> followed by a EMFT CommandChangeDescription. This last manage the undo
> for precommit but give no information when using its accessor
> getObjectChanges()/getObjectsToDetach()/getObjectsToAttach(). It's too
> bad to not have its information because recompute them in postcommit
> from the list of notifications can be costly. If don't understand why we
> have this CommandChangeDescription and the TriggerCommandTransaction
> which prevent us to use ChangeDescription accessors. Would it be
> possible to have these accessors usable in EMF Transaction use case?
>
> Cheers.
>
> Le 13/02/2015 15:07, Esteban Dugueperoux a écrit :
>> Hi Christian,
>>
>> Indeed I was lost in transaction :)
>> As in postcommit Transaction.getChangeDescription() return always null,
>> I have plugged a ValidateEditSupport to keep a reference to this
>> ChangeDescription on call to ValidateEditSupport.finalizeForCommit()
>> method.
>>
>> After a little analysis, I reproduce my issue when I have 2 resources in
>> my ResourceSet and that initial command add an object in the first
>> resource and the precommit in the second resource. I have attached a
>> test case to reproduce.
>>
>> Best Regards.
>>
>> Le 11/02/2015 17:45, Christian W. Damus a écrit :
>>> Hi, Esteban,
>>>
>>> After the transaction has committed (for example, in a post-commit
>>> listener), all of the changes made by that transaction, including
>>> triggers, should be included. Otherwise it could never be properly
>>> rolled back or undone. Even non-EMF changes can be included by triggers
>>> that use commands to effect changes to stuff outside of the model.
>>>
>>> You may find that changes made by triggers are buried in some kind of
>>> crazy nested composite change description structure ...
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
>>>
>>>> Hi EMF Community,
>>>>
>>>> In our EMF Transaction based application, we need to know which
>>>> objects have been changed/added/removed after a transaction commit. We
>>>> have seen Transaction.getChangeDescription() API can be used for this
>>>> but changes of precommits, i.e. ResourceSetListener, are not included.
>>>> This is a know issue or i'm confused?
>>>>
>>>> Best Regards.
|
|
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1622162 is a reply to message #1620861] |
Wed, 18 February 2015 09:55 |
Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=460206 with
a little patch containing some tests and a draft of fix not satisfying
yet. I don't know how to correctly do the work and I would appreciate
your advice.
Best Regards.
Le 17/02/2015 14:39, Christian W. Damus a écrit :
> Hi, Esteban,
>
> Thanks for digging deeper. Indeed, it would seem that the
> CommandChangeDescription is not quite fulfilling the contract of the
> interface that it implements if it does, indeed, encapsulate EMF
> changes. It wasn't anticipated that clients would actually want to
> access this information; the change descriptions were only really
> intended to support roll-back and undo/redo, which is an internal concern.
>
> I have no doubt that it would be possible to publish those EMF changes
> in the CommandChangeDescription. You may want to work up a patch
> contribution in Bugzilla.
>
> Cheers,
>
> Christian
>
> On 2015-02-16 09:56:52 +0000, Esteban Dugueperoux said:
>
>> Hi Christian,
>>
>> I have updated my tests and my analysis, when the main command and the
>> one from precommit add a EClass on the same EPackage
>> ChangeDescription.getObjectsToDetach() return both EClasses. In opposite
>> if precommit add its EClass to another EPackage,
>> ChangeDescription.getObjectsToDetach() returns only the added EClass
>> from the main command.
>>
>> In both cases, the ChangeDescription returned by the Transaction is a
>> EMFT CompositeChangeDescription composed of an EMF ChangeDescriptionImpl
>> followed by a EMFT CommandChangeDescription. This last manage the undo
>> for precommit but give no information when using its accessor
>> getObjectChanges()/getObjectsToDetach()/getObjectsToAttach(). It's too
>> bad to not have its information because recompute them in postcommit
>> from the list of notifications can be costly. If don't understand why we
>> have this CommandChangeDescription and the TriggerCommandTransaction
>> which prevent us to use ChangeDescription accessors. Would it be
>> possible to have these accessors usable in EMF Transaction use case?
>>
>> Cheers.
>>
>> Le 13/02/2015 15:07, Esteban Dugueperoux a écrit :
>>> Hi Christian,
>>>
>>> Indeed I was lost in transaction :)
>>> As in postcommit Transaction.getChangeDescription() return always null,
>>> I have plugged a ValidateEditSupport to keep a reference to this
>>> ChangeDescription on call to ValidateEditSupport.finalizeForCommit()
>>> method.
>>>
>>> After a little analysis, I reproduce my issue when I have 2 resources in
>>> my ResourceSet and that initial command add an object in the first
>>> resource and the precommit in the second resource. I have attached a
>>> test case to reproduce.
>>>
>>> Best Regards.
>>>
>>> Le 11/02/2015 17:45, Christian W. Damus a écrit :
>>>> Hi, Esteban,
>>>>
>>>> After the transaction has committed (for example, in a post-commit
>>>> listener), all of the changes made by that transaction, including
>>>> triggers, should be included. Otherwise it could never be properly
>>>> rolled back or undone. Even non-EMF changes can be included by
>>>> triggers
>>>> that use commands to effect changes to stuff outside of the model.
>>>>
>>>> You may find that changes made by triggers are buried in some kind of
>>>> crazy nested composite change description structure ...
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
>>>>
>>>>> Hi EMF Community,
>>>>>
>>>>> In our EMF Transaction based application, we need to know which
>>>>> objects have been changed/added/removed after a transaction commit. We
>>>>> have seen Transaction.getChangeDescription() API can be used for this
>>>>> but changes of precommits, i.e. ResourceSetListener, are not included.
>>>>> This is a know issue or i'm confused?
>>>>>
>>>>> Best Regards.
>
>
--
Esteban Dugueperoux - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF Transaction] Transaction.getChangeDescription() [message #1628306 is a reply to message #1622162] |
Sun, 22 February 2015 02:35 |
|
Hi, Esteban,
The test class looks good. Interesting use of a post-commit listener
that is a ValidateEditSupport: I've never seen anything like that
before! ;-) I don't know why you think it's necessary: the
Transaction provided by the ResourceSetChangedEvent always still has
its ChangeDescription.
Your proposed change does introduce a regression:
-------- 8< --------
Command Undo/Redo Tests (org.eclipse.emf.transaction.tests.UndoRedoTest)
test_nonredoableTriggerCommand_RecordingCommand_138287()
-------- >8 --------
I have updated the bugzilla with a new patch that fixes the problem.
At least, it makes your test cases pass and doesn't cause any existing
regression tests to fail.
Cheers,
Christian
On 2015-02-18 09:55:17 +0000, Esteban Dugueperoux said:
> Hi Christian,
>
> I have raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=460206 with
> a little patch containing some tests and a draft of fix not satisfying
> yet. I don't know how to correctly do the work and I would appreciate
> your advice.
>
> Best Regards.
>
> Le 17/02/2015 14:39, Christian W. Damus a écrit :
>> Hi, Esteban,
>>
>> Thanks for digging deeper. Indeed, it would seem that the
>> CommandChangeDescription is not quite fulfilling the contract of the
>> interface that it implements if it does, indeed, encapsulate EMF
>> changes. It wasn't anticipated that clients would actually want to
>> access this information; the change descriptions were only really
>> intended to support roll-back and undo/redo, which is an internal concern.
>>
>> I have no doubt that it would be possible to publish those EMF changes
>> in the CommandChangeDescription. You may want to work up a patch
>> contribution in Bugzilla.
>>
>> Cheers,
>>
>> Christian
>>
>> On 2015-02-16 09:56:52 +0000, Esteban Dugueperoux said:
>>
>>> Hi Christian,
>>>
>>> I have updated my tests and my analysis, when the main command and the
>>> one from precommit add a EClass on the same EPackage
>>> ChangeDescription.getObjectsToDetach() return both EClasses. In opposite
>>> if precommit add its EClass to another EPackage,
>>> ChangeDescription.getObjectsToDetach() returns only the added EClass
>>> from the main command.
>>>
>>> In both cases, the ChangeDescription returned by the Transaction is a
>>> EMFT CompositeChangeDescription composed of an EMF ChangeDescriptionImpl
>>> followed by a EMFT CommandChangeDescription. This last manage the undo
>>> for precommit but give no information when using its accessor
>>> getObjectChanges()/getObjectsToDetach()/getObjectsToAttach(). It's too
>>> bad to not have its information because recompute them in postcommit
>>> from the list of notifications can be costly. If don't understand why we
>>> have this CommandChangeDescription and the TriggerCommandTransaction
>>> which prevent us to use ChangeDescription accessors. Would it be
>>> possible to have these accessors usable in EMF Transaction use case?
>>>
>>> Cheers.
>>>
>>> Le 13/02/2015 15:07, Esteban Dugueperoux a écrit :
>>>> Hi Christian,
>>>>
>>>> Indeed I was lost in transaction :)
>>>> As in postcommit Transaction.getChangeDescription() return always null,
>>>> I have plugged a ValidateEditSupport to keep a reference to this
>>>> ChangeDescription on call to ValidateEditSupport.finalizeForCommit()
>>>> method.
>>>>
>>>> After a little analysis, I reproduce my issue when I have 2 resources in
>>>> my ResourceSet and that initial command add an object in the first
>>>> resource and the precommit in the second resource. I have attached a
>>>> test case to reproduce.
>>>>
>>>> Best Regards.
>>>>
>>>> Le 11/02/2015 17:45, Christian W. Damus a écrit :
>>>>> Hi, Esteban,
>>>>>
>>>>> After the transaction has committed (for example, in a post-commit
>>>>> listener), all of the changes made by that transaction, including
>>>>> triggers, should be included. Otherwise it could never be properly
>>>>> rolled back or undone. Even non-EMF changes can be included by
>>>>> triggers
>>>>> that use commands to effect changes to stuff outside of the model.
>>>>>
>>>>> You may find that changes made by triggers are buried in some kind of
>>>>> crazy nested composite change description structure ...
>>>>>
>>>>> HTH,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On 2015-02-11 15:54:56 +0000, Esteban Dugueperoux said:
>>>>>
>>>>>> Hi EMF Community,
>>>>>>
>>>>>> In our EMF Transaction based application, we need to know which
>>>>>> objects have been changed/added/removed after a transaction commit. We
>>>>>> have seen Transaction.getChangeDescription() API can be used for this
>>>>>> but changes of precommits, i.e. ResourceSetListener, are not included.
>>>>>> This is a know issue or i'm confused?
>>>>>>
>>>>>> Best Regards.
|
|
|
Goto Forum:
Current Time: Tue Apr 23 08:00:23 GMT 2024
Powered by FUDForum. Page generated in 0.03481 seconds |
] 
Search
Help
Register
Login
Home
