Home » Modeling » EMF » [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ?
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427359 is a reply to message #427357] |
Fri, 13 February 2009 16:19   |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Stéphane,
I can't really tell you why you experience this, but I suspect it could
be related with something I experienced while working in the CDO + GMF
integration. The default CDOResoure implementation (CDOResourceImpl)
does implement org.eclipse.emf.ecore.resource.Resource, but it *does
not* extend org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of
the functionality of this "internal" (please note the quoting of
internal, as it seem EMF internals are freely used :P) is not present in
CDOResourceImpl. I recall some of the generated code from GMF was
heavily dependant on ResourceImpl internals.
So unfortunately, many projects rely in the internals of ResourceImpl,
for instance, ModificationTrackingAdapter. It could be related with what
you've exposed. I would suggest you to make some debugging (sometimes
it's fun :P) and observe how does the TransactionalEditingDomain manage
XMIResources.
There are other suspicious indicators on how EMF Transaction "detects"
resource changes:
- Take a look at the Adapters installed in the Resource. ResourceImpl
carries some adapters CDOResourceImpl does not.
- workspace deltas fire change notifications. since CDOResource is not
in the workspace... no deltas...
I'm afraid I can't say much more, it's a matter of debugging.
If you find some behavior in "ResourceImpl" that "CDOResourceImpl" does
not have, please let us know and we will try to implement it.
HTH,
ViK.
Stéphane Fournier escribió:
> Hi,
>
> I am using the code of the CDO StandaloneManualExample class.
>
> I change some pieces of code to use a TransactionalEditingDomain (TED).
>
> First, I get the resourceSet from a TED then I open a CDO transaction
> with this resourceSet.
> I load an existing resource and add it a new object.
> Finally, I commit the transaction.
> That runs smoothly.
>
> That's weird, because if the resource is not a CDO one but an XMI one
> for instance, an exception is raised to warn model changes have to be
> done in a write transaction. This is a standard behavior when using TED.
>
> I was also expecting this behavior with a CDO resource.
>
> Is it a normal behavior for CDO resources ?
>
> Stephane.
>
>
>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427360 is a reply to message #427359] |
Fri, 13 February 2009 16:26 |
|
Víctor Roldán Betancort schrieb:
> Stéphane,
>
> I can't really tell you why you experience this, but I suspect it
> could be related with something I experienced while working in the CDO
> + GMF integration. The default CDOResoure implementation
> (CDOResourceImpl) does implement
> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
> functionality of this "internal" (please note the quoting of internal,
> as it seem EMF internals are freely used :P)
Oh no, Ed will start kidding me again!
Look at the Javadoc of Resource... ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
> is not present in CDOResourceImpl. I recall some of the generated code
> from GMF was heavily dependant on ResourceImpl internals.
>
> So unfortunately, many projects rely in the internals of ResourceImpl,
> for instance, ModificationTrackingAdapter. It could be related with
> what you've exposed. I would suggest you to make some debugging
> (sometimes it's fun :P) and observe how does the
> TransactionalEditingDomain manage XMIResources.
>
> There are other suspicious indicators on how EMF Transaction "detects"
> resource changes:
>
> - Take a look at the Adapters installed in the Resource. ResourceImpl
> carries some adapters CDOResourceImpl does not.
> - workspace deltas fire change notifications. since CDOResource is not
> in the workspace... no deltas...
>
> I'm afraid I can't say much more, it's a matter of debugging.
> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
> does not have, please let us know and we will try to implement it.
>
> HTH,
> ViK.
>
>
> Stéphane Fournier escribió:
>> Hi,
>>
>> I am using the code of the CDO StandaloneManualExample class.
>>
>> I change some pieces of code to use a TransactionalEditingDomain (TED).
>>
>> First, I get the resourceSet from a TED then I open a CDO transaction
>> with this resourceSet.
>> I load an existing resource and add it a new object.
>> Finally, I commit the transaction.
>> That runs smoothly.
>>
>> That's weird, because if the resource is not a CDO one but an XMI one
>> for instance, an exception is raised to warn model changes have to be
>> done in a write transaction. This is a standard behavior when using TED.
>>
>> I was also expecting this behavior with a CDO resource.
>>
>> Is it a normal behavior for CDO resources ?
>>
>> Stephane.
>>
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427365 is a reply to message #427359] |
Fri, 13 February 2009 22:08 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Víctor, Stéphane,
The TransactionalEditingDomain uses a TransactionChangeRecorder to
record changes for rollback. This is how it usually detects that
changes occur outside of a transaction context. The
TransactionChangeRecorder acts like an EContentAdapter, propagating
itself from the ResourceSet down into the contents of all of its resources.
It sounds as though the change recorder is not being attached to the
CDOResource, or perhaps not to its contents? Perhaps there is a problem
in the dual nature of the CDOResource, which is a Resource *and* an
EObject. What does it respond to an eContents() query? It could be
that the TransactionChangeRecorder sees the resource as an EObject and
tries to propagate itself to the eContents(), but there aren't any
because it's actually a Resource that has getContents() ?
Just speculating ...
cW
Víctor Roldán Betancort wrote:
> Stéphane,
>
> I can't really tell you why you experience this, but I suspect it could
> be related with something I experienced while working in the CDO + GMF
> integration. The default CDOResoure implementation (CDOResourceImpl)
> does implement org.eclipse.emf.ecore.resource.Resource, but it *does
> not* extend org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of
> the functionality of this "internal" (please note the quoting of
> internal, as it seem EMF internals are freely used :P) is not present in
> CDOResourceImpl. I recall some of the generated code from GMF was
> heavily dependant on ResourceImpl internals.
>
> So unfortunately, many projects rely in the internals of ResourceImpl,
> for instance, ModificationTrackingAdapter. It could be related with what
> you've exposed. I would suggest you to make some debugging (sometimes
> it's fun :P) and observe how does the TransactionalEditingDomain manage
> XMIResources.
>
> There are other suspicious indicators on how EMF Transaction "detects"
> resource changes:
>
> - Take a look at the Adapters installed in the Resource. ResourceImpl
> carries some adapters CDOResourceImpl does not.
> - workspace deltas fire change notifications. since CDOResource is not
> in the workspace... no deltas...
>
> I'm afraid I can't say much more, it's a matter of debugging.
> If you find some behavior in "ResourceImpl" that "CDOResourceImpl" does
> not have, please let us know and we will try to implement it.
>
> HTH,
> ViK.
>
>
> Stéphane Fournier escribió:
>> Hi,
>>
>> I am using the code of the CDO StandaloneManualExample class.
>>
>> I change some pieces of code to use a TransactionalEditingDomain (TED).
>>
>> First, I get the resourceSet from a TED then I open a CDO transaction
>> with this resourceSet.
>> I load an existing resource and add it a new object.
>> Finally, I commit the transaction.
>> That runs smoothly.
>>
>> That's weird, because if the resource is not a CDO one but an XMI one
>> for instance, an exception is raised to warn model changes have to be
>> done in a write transaction. This is a standard behavior when using TED.
>>
>> I was also expecting this behavior with a CDO resource.
>>
>> Is it a normal behavior for CDO resources ?
>>
>> Stephane.
>>
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427378 is a reply to message #427365] |
Mon, 16 February 2009 09:09 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi Christian, Eike, Victor,
This morning, I'm debugging my problem and here is my analysis :
The TransactionChangeRecorder is well registered on the CDOResource.
When adding an object into its content, the notifyChanged(..) method is
called.
Neverthesless, the CDOResource is not considered as a loaded one by the
ResourceSetManager (EMF Transaction framework) and the 'record' variable
is set to false. Then, the notification is handled by the
ChangeRecorder#notifyChanged(..).
As you mentioned Christian, the notifier is tested against EObject first.
As the CDOResource is also an EObject, we enters this case. The
notification is then handled by ChangeRecorder#handleFeature(..)
I try to investigate why the CDO resource is not considered as a loaded
one by the ResourceSetManager whereas CDOResource.loaded attribute is set
to true.
Stephane.
Christian W. Damus wrote:
> Hi, Víctor, Stéphane,
> The TransactionalEditingDomain uses a TransactionChangeRecorder to
> record changes for rollback. This is how it usually detects that
> changes occur outside of a transaction context. The
> TransactionChangeRecorder acts like an EContentAdapter, propagating
> itself from the ResourceSet down into the contents of all of its resources.
> It sounds as though the change recorder is not being attached to the
> CDOResource, or perhaps not to its contents? Perhaps there is a problem
> in the dual nature of the CDOResource, which is a Resource *and* an
> EObject. What does it respond to an eContents() query? It could be
> that the TransactionChangeRecorder sees the resource as an EObject and
> tries to propagate itself to the eContents(), but there aren't any
> because it's actually a Resource that has getContents() ?
> Just speculating ...
> cW
> Víctor Roldán Betancort wrote:
>> Stéphane,
>>
>> I can't really tell you why you experience this, but I suspect it could
>> be related with something I experienced while working in the CDO + GMF
>> integration. The default CDOResoure implementation (CDOResourceImpl)
>> does implement org.eclipse.emf.ecore.resource.Resource, but it *does
>> not* extend org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of
>> the functionality of this "internal" (please note the quoting of
>> internal, as it seem EMF internals are freely used :P) is not present in
>> CDOResourceImpl. I recall some of the generated code from GMF was
>> heavily dependant on ResourceImpl internals.
>>
>> So unfortunately, many projects rely in the internals of ResourceImpl,
>> for instance, ModificationTrackingAdapter. It could be related with what
>> you've exposed. I would suggest you to make some debugging (sometimes
>> it's fun :P) and observe how does the TransactionalEditingDomain manage
>> XMIResources.
>>
>> There are other suspicious indicators on how EMF Transaction "detects"
>> resource changes:
>>
>> - Take a look at the Adapters installed in the Resource. ResourceImpl
>> carries some adapters CDOResourceImpl does not.
>> - workspace deltas fire change notifications. since CDOResource is not
>> in the workspace... no deltas...
>>
>> I'm afraid I can't say much more, it's a matter of debugging.
>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl" does
>> not have, please let us know and we will try to implement it.
>>
>> HTH,
>> ViK.
>>
>>
>> Stéphane Fournier escribió:
>>> Hi,
>>>
>>> I am using the code of the CDO StandaloneManualExample class.
>>>
>>> I change some pieces of code to use a TransactionalEditingDomain (TED).
>>>
>>> First, I get the resourceSet from a TED then I open a CDO transaction
>>> with this resourceSet.
>>> I load an existing resource and add it a new object.
>>> Finally, I commit the transaction.
>>> That runs smoothly.
>>>
>>> That's weird, because if the resource is not a CDO one but an XMI one
>>> for instance, an exception is raised to warn model changes have to be
>>> done in a write transaction. This is a standard behavior when using TED.
>>>
>>> I was also expecting this behavior with a CDO resource.
>>>
>>> Is it a normal behavior for CDO resources ?
>>>
>>> Stephane.
>>>
>>>
>>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427380 is a reply to message #427378] |
Mon, 16 February 2009 11:55 |
|
Christian and Stephane,
Thanks for your enthusiasm! I'm currently over-busy with writing an article.
I think I'll be finished tomorrow and can jump in here ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Stéphane Fournier schrieb:
> Hi Christian, Eike, Victor,
>
> This morning, I'm debugging my problem and here is my analysis :
>
> The TransactionChangeRecorder is well registered on the CDOResource.
> When adding an object into its content, the notifyChanged(..) method
> is called.
> Neverthesless, the CDOResource is not considered as a loaded one by
> the ResourceSetManager (EMF Transaction framework) and the 'record'
> variable is set to false. Then, the notification is handled by the
> ChangeRecorder#notifyChanged(..). As you mentioned Christian, the
> notifier is tested against EObject first. As the CDOResource is also
> an EObject, we enters this case. The notification is then handled by
> ChangeRecorder#handleFeature(..)
>
> I try to investigate why the CDO resource is not considered as a
> loaded one by the ResourceSetManager whereas CDOResource.loaded
> attribute is set to true.
>
> Stephane.
>
> Christian W. Damus wrote:
>
>> Hi, Víctor, Stéphane,
>
>> The TransactionalEditingDomain uses a TransactionChangeRecorder to
>> record changes for rollback. This is how it usually detects that
>> changes occur outside of a transaction context. The
>> TransactionChangeRecorder acts like an EContentAdapter, propagating
>> itself from the ResourceSet down into the contents of all of its
>> resources.
>
>> It sounds as though the change recorder is not being attached to the
>> CDOResource, or perhaps not to its contents? Perhaps there is a
>> problem in the dual nature of the CDOResource, which is a Resource
>> *and* an EObject. What does it respond to an eContents() query? It
>> could be that the TransactionChangeRecorder sees the resource as an
>> EObject and tries to propagate itself to the eContents(), but there
>> aren't any because it's actually a Resource that has getContents() ?
>
>> Just speculating ...
>
>> cW
>
>> Víctor Roldán Betancort wrote:
>>> Stéphane,
>>>
>>> I can't really tell you why you experience this, but I suspect it
>>> could be related with something I experienced while working in the
>>> CDO + GMF integration. The default CDOResoure implementation
>>> (CDOResourceImpl) does implement
>>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>>> functionality of this "internal" (please note the quoting of
>>> internal, as it seem EMF internals are freely used :P) is not
>>> present in CDOResourceImpl. I recall some of the generated code from
>>> GMF was heavily dependant on ResourceImpl internals.
>>>
>>> So unfortunately, many projects rely in the internals of
>>> ResourceImpl, for instance, ModificationTrackingAdapter. It could be
>>> related with what you've exposed. I would suggest you to make some
>>> debugging (sometimes it's fun :P) and observe how does the
>>> TransactionalEditingDomain manage XMIResources.
>>>
>>> There are other suspicious indicators on how EMF Transaction
>>> "detects" resource changes:
>>>
>>> - Take a look at the Adapters installed in the Resource.
>>> ResourceImpl carries some adapters CDOResourceImpl does not.
>>> - workspace deltas fire change notifications. since CDOResource is
>>> not in the workspace... no deltas...
>>>
>>> I'm afraid I can't say much more, it's a matter of debugging.
>>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>>> does not have, please let us know and we will try to implement it.
>>>
>>> HTH,
>>> ViK.
>>>
>>>
>>> Stéphane Fournier escribió:
>>>> Hi,
>>>>
>>>> I am using the code of the CDO StandaloneManualExample class.
>>>>
>>>> I change some pieces of code to use a TransactionalEditingDomain
>>>> (TED).
>>>>
>>>> First, I get the resourceSet from a TED then I open a CDO
>>>> transaction with this resourceSet.
>>>> I load an existing resource and add it a new object.
>>>> Finally, I commit the transaction.
>>>> That runs smoothly.
>>>>
>>>> That's weird, because if the resource is not a CDO one but an XMI
>>>> one for instance, an exception is raised to warn model changes have
>>>> to be done in a write transaction. This is a standard behavior when
>>>> using TED.
>>>>
>>>> I was also expecting this behavior with a CDO resource.
>>>>
>>>> Is it a normal behavior for CDO resources ?
>>>>
>>>> Stephane.
>>>>
>>>>
>>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427384 is a reply to message #427380] |
Mon, 16 February 2009 12:27 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Everybody,
I tested some changes :
1) in CDOResourceImpl#load(Map<?, ?> options), the call to setLoaded is
changed to send the created notification (by setLoaded(true)).
Notification notification = setLoaded(true);
if (notification != null)
{
eNotify(notification);
}
Registered adapters are notified (e.g TransactionChangeRecorder) that the
resource is loaded now.
2) In CDOResourceImpl#setLoaded(..) the integer returned by the
getFeatureID(Class<?> expectedClass) is
EresourcePackage.CDO_RESOURCE__LOADED which is valuated to 7. I replaced
that value in this notification by Resource.RESOURCE__IS_LOADED (#4)
because ResourceSetManager is only dealing with Resource constants.
Eike, does it mean something different between these 2 constants ? If the
meaning is similar, having a common value would be useful.
With this change, the CDOResource is considered as loaded by the
ResourceSetManager.
Despite theses changes, I don't catch changes on the resource content or
changes on contained objects (e.g a set name on a contained company) in
the TransactionChangeRecorder... arghh
Does someone have an idea ?
I can provide the StandaloneManualExample code slightly modified to take
into accound a TED, if some of you have a couple of minutes to investigate
too...
Stephane.
Eike Stepper wrote:
> Christian and Stephane,
> Thanks for your enthusiasm! I'm currently over-busy with writing an article.
> I think I'll be finished tomorrow and can jump in here ;-)
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
> Stéphane Fournier schrieb:
>> Hi Christian, Eike, Victor,
>>
>> This morning, I'm debugging my problem and here is my analysis :
>>
>> The TransactionChangeRecorder is well registered on the CDOResource.
>> When adding an object into its content, the notifyChanged(..) method
>> is called.
>> Neverthesless, the CDOResource is not considered as a loaded one by
>> the ResourceSetManager (EMF Transaction framework) and the 'record'
>> variable is set to false. Then, the notification is handled by the
>> ChangeRecorder#notifyChanged(..). As you mentioned Christian, the
>> notifier is tested against EObject first. As the CDOResource is also
>> an EObject, we enters this case. The notification is then handled by
>> ChangeRecorder#handleFeature(..)
>>
>> I try to investigate why the CDO resource is not considered as a
>> loaded one by the ResourceSetManager whereas CDOResource.loaded
>> attribute is set to true.
>>
>> Stephane.
>>
>> Christian W. Damus wrote:
>>
>>> Hi, Víctor, Stéphane,
>>
>>> The TransactionalEditingDomain uses a TransactionChangeRecorder to
>>> record changes for rollback. This is how it usually detects that
>>> changes occur outside of a transaction context. The
>>> TransactionChangeRecorder acts like an EContentAdapter, propagating
>>> itself from the ResourceSet down into the contents of all of its
>>> resources.
>>
>>> It sounds as though the change recorder is not being attached to the
>>> CDOResource, or perhaps not to its contents? Perhaps there is a
>>> problem in the dual nature of the CDOResource, which is a Resource
>>> *and* an EObject. What does it respond to an eContents() query? It
>>> could be that the TransactionChangeRecorder sees the resource as an
>>> EObject and tries to propagate itself to the eContents(), but there
>>> aren't any because it's actually a Resource that has getContents() ?
>>
>>> Just speculating ...
>>
>>> cW
>>
>>> Víctor Roldán Betancort wrote:
>>>> Stéphane,
>>>>
>>>> I can't really tell you why you experience this, but I suspect it
>>>> could be related with something I experienced while working in the
>>>> CDO + GMF integration. The default CDOResoure implementation
>>>> (CDOResourceImpl) does implement
>>>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>>>> functionality of this "internal" (please note the quoting of
>>>> internal, as it seem EMF internals are freely used :P) is not
>>>> present in CDOResourceImpl. I recall some of the generated code from
>>>> GMF was heavily dependant on ResourceImpl internals.
>>>>
>>>> So unfortunately, many projects rely in the internals of
>>>> ResourceImpl, for instance, ModificationTrackingAdapter. It could be
>>>> related with what you've exposed. I would suggest you to make some
>>>> debugging (sometimes it's fun :P) and observe how does the
>>>> TransactionalEditingDomain manage XMIResources.
>>>>
>>>> There are other suspicious indicators on how EMF Transaction
>>>> "detects" resource changes:
>>>>
>>>> - Take a look at the Adapters installed in the Resource.
>>>> ResourceImpl carries some adapters CDOResourceImpl does not.
>>>> - workspace deltas fire change notifications. since CDOResource is
>>>> not in the workspace... no deltas...
>>>>
>>>> I'm afraid I can't say much more, it's a matter of debugging.
>>>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>>>> does not have, please let us know and we will try to implement it.
>>>>
>>>> HTH,
>>>> ViK.
>>>>
>>>>
>>>> Stéphane Fournier escribió:
>>>>> Hi,
>>>>>
>>>>> I am using the code of the CDO StandaloneManualExample class.
>>>>>
>>>>> I change some pieces of code to use a TransactionalEditingDomain
>>>>> (TED).
>>>>>
>>>>> First, I get the resourceSet from a TED then I open a CDO
>>>>> transaction with this resourceSet.
>>>>> I load an existing resource and add it a new object.
>>>>> Finally, I commit the transaction.
>>>>> That runs smoothly.
>>>>>
>>>>> That's weird, because if the resource is not a CDO one but an XMI
>>>>> one for instance, an exception is raised to warn model changes have
>>>>> to be done in a write transaction. This is a standard behavior when
>>>>> using TED.
>>>>>
>>>>> I was also expecting this behavior with a CDO resource.
>>>>>
>>>>> Is it a normal behavior for CDO resources ?
>>>>>
>>>>> Stephane.
>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427386 is a reply to message #427384] |
Mon, 16 February 2009 12:46 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Stéphane,
comments below:
Stéphane Fournier escribió:
> Everybody,
>
> I tested some changes :
> 1) in CDOResourceImpl#load(Map<?, ?> options), the call to setLoaded is
> changed to send the created notification (by setLoaded(true)).
> Notification notification = setLoaded(true);
> if (notification != null)
> {
> eNotify(notification);
> }
> Registered adapters are notified (e.g TransactionChangeRecorder) that
> the resource is loaded now.
We had a bug related with isLoaded. Feel free to share your code and
expose your comments. If CDOResourceImpl is not notifying its load, and
ResourceImpl, then we should implement it :)
248296: Manage the "isLoaded" property of CDOResource
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248296
> 2) In CDOResourceImpl#setLoaded(..) the integer returned by the
> getFeatureID(Class<?> expectedClass) is
> EresourcePackage.CDO_RESOURCE__LOADED which is valuated to 7. I replaced
> that value in this notification by Resource.RESOURCE__IS_LOADED (#4)
> because ResourceSetManager is only dealing with Resource constants.
> Eike, does it mean something different between these 2 constants ? If
> the meaning is similar, having a common value would be useful.
> With this change, the CDOResource is considered as loaded by the
> ResourceSetManager.
>
> Despite theses changes, I don't catch changes on the resource content or
> changes on contained objects (e.g a set name on a contained company) in
> the TransactionChangeRecorder... arghh
>
> Does someone have an idea ?
It reminds me this:
252242: Resource.setModified() should notify adapters when called
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252242
I experienced that GMF editor didn't get dirty upon CDOObject
modifications. This bug should fix it.
I have a quick and dirty hack for this, try it but only to determine if
this is related with you problem. We should come with a more optimal
approach to solve this bug. See the code below in
org.eclipse.emf.internal.cdo.CDOStateMachine.
/**
* @author Eike Stepper
*/
private final class WriteTransition implements ITransition<CDOState,
CDOEvent, InternalCDOObject, Object>
{
public void execute(InternalCDOObject object, CDOState state,
CDOEvent event, Object featureDelta)
{
// Copy revision
InternalCDORevision revision =
(InternalCDORevision)object.cdoRevision().copy();
revision.setTransactional();
object.cdoInternalSetRevision(revision);
InternalCDOView view = object.cdoView();
InternalCDOTransaction transaction = view.toTransaction();
transaction.registerDirty(object, (CDOFeatureDelta)featureDelta);
changeState(object, CDOState.DIRTY);
if (object.cdoResource() != null)
{
object.cdoResource().setModified(true);
}
}
}
Notice the added:
if (object.cdoResource() != null)
{
object.cdoResource().setModified(true);
}
If a Object is modified (set to dirty), we put the isModified attribute
of the container resource to true. This is not optimal because the tree
path that reaches this object might not be loaded, so it requests
several objects to be loaded.
Let me know if it works for you.
Cheers,
Víctor.
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427391 is a reply to message #427386] |
Mon, 16 February 2009 15:25 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Victor,
comments below :
Víctor Roldán Betancort wrote:
> Stéphane,
> comments below:
> Stéphane Fournier escribió:
>> Everybody,
>>
>> I tested some changes :
>> 1) in CDOResourceImpl#load(Map<?, ?> options), the call to setLoaded is
>> changed to send the created notification (by setLoaded(true)).
>> Notification notification = setLoaded(true);
>> if (notification != null)
>> {
>> eNotify(notification);
>> }
>> Registered adapters are notified (e.g TransactionChangeRecorder) that
>> the resource is loaded now.
> We had a bug related with isLoaded. Feel free to share your code and
> expose your comments. If CDOResourceImpl is not notifying its load, and
> ResourceImpl, then we should implement it :)
> 248296: Manage the "isLoaded" property of CDOResource
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=248296
I have added a comment to this bug.
>> 2) In CDOResourceImpl#setLoaded(..) the integer returned by the
>> getFeatureID(Class<?> expectedClass) is
>> EresourcePackage.CDO_RESOURCE__LOADED which is valuated to 7. I replaced
>> that value in this notification by Resource.RESOURCE__IS_LOADED (#4)
>> because ResourceSetManager is only dealing with Resource constants.
>> Eike, does it mean something different between these 2 constants ? If
>> the meaning is similar, having a common value would be useful.
>> With this change, the CDOResource is considered as loaded by the
>> ResourceSetManager.
>>
>> Despite theses changes, I don't catch changes on the resource content or
>> changes on contained objects (e.g a set name on a contained company) in
>> the TransactionChangeRecorder... arghh
>>
>> Does someone have an idea ?
> It reminds me this:
> 252242: Resource.setModified() should notify adapters when called
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252242
> I experienced that GMF editor didn't get dirty upon CDOObject
> modifications. This bug should fix it.
> I have a quick and dirty hack for this, try it but only to determine if
> this is related with you problem. We should come with a more optimal
> approach to solve this bug. See the code below in
> org.eclipse.emf.internal.cdo.CDOStateMachine.
> /**
> * @author Eike Stepper
> */
> private final class WriteTransition implements ITransition<CDOState,
> CDOEvent, InternalCDOObject, Object>
> {
> public void execute(InternalCDOObject object, CDOState state,
> CDOEvent event, Object featureDelta)
> {
> // Copy revision
> InternalCDORevision revision =
> (InternalCDORevision)object.cdoRevision().copy();
> revision.setTransactional();
> object.cdoInternalSetRevision(revision);
> InternalCDOView view = object.cdoView();
> InternalCDOTransaction transaction = view.toTransaction();
> transaction.registerDirty(object, (CDOFeatureDelta)featureDelta);
> changeState(object, CDOState.DIRTY);
> if (object.cdoResource() != null)
> {
> object.cdoResource().setModified(true);
> }
> }
> }
> Notice the added:
> if (object.cdoResource() != null)
> {
> object.cdoResource().setModified(true);
> }
> If a Object is modified (set to dirty), we put the isModified attribute
> of the container resource to true. This is not optimal because the tree
> path that reaches this object might not be loaded, so it requests
> several objects to be loaded.
> Let me know if it works for you.
It changes nothing.
Here we are !!
As Christian mentioned, the CDOResource is both a resource and an EObject.
I modified the ChangeRecorder itself in org.eclipse.emf.ecore.change
plug-in to switch code in the notifyChanged(..) method.
I realized the objects contained in the CDO resource do not have the
TransactionChangeRecorder registered as an EMF adapter.
In switching Resource and EObject "if else" statements, that registers
correctly the resource adapters on its content.
Now, if I modify some objects without an EMF transaction, I get the
expected exception : that the model has to be changed within a write
transaction.
I'm not completely satisfied because when registering adapters in
ChangeRecorder#notifyChanged method, that forces to load the resource
content.
A better way would be to register the adapters on resource content lazily.
Do you have idea where is the best location to do that ?
Could you please confirm the changes I did make sense ?
Stephane.
To sum up, here are the changes I did:
1) send the notification in CDOResourceImpl#load(Map<?, ?> options)
2) change the integer value to Resource.RESOURCE__IS_LOADED in the
notification created to notify the loaded resource.
3) switch if else statement to ensure Resource case is handled before
EObject case in ChangeRecorder#notifyChanged (EMF framework)
> Cheers,
> Víctor.
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427401 is a reply to message #427391] |
Mon, 16 February 2009 20:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Stéphane, Víctor,
I've been out of commission for a few days, so I hope I'm not too late
in following up.
Are there any changes that you will need in the EMF Transaction API,
that will make sense in the general EMF context? For example, the
possibility of objects being simultaneously EObjects and Resources is
something that we could account for by changing the order of these
tests, as you have done. Although, there may be performance impact ...
Perhaps more appropriate would be changes that make it easier for CDO to
plug in custom handling of its resources and objects. I haven't given
it much thought.
If you have a need, don't hesitate to raise enhancement requests in
bugzilla (and attach patches! ;-)
cW
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427406 is a reply to message #427365] |
Tue, 17 February 2009 09:35 |
|
Guys,
As I said, I was kind of mentally occupied in the last time. Now I read
this thread and the other one by Stephane which may be related. I have
problems to get everything in the proper context.
Stephane, would you mind telling me again:
1) What are you trying do achieve (integrate CDO with GMF or TED or...)?
2) Which version of CDO are you using therefor?
3) Which problem did appear?
4) Do you already suspect a reason for it?
Christian, you asked "What does CDOResource respond to an eContents()
query?".
CDOResourceImpl does not override BasicEObjectImpl.eContents().
As a consequence it returns the value of the only modeled containment
feature "contents", i.e. the same as getContents().
Stephane, you mentioned a mismatch between EMF and CDO featureID values.
I guess that was not our intention. They should be identical. Did you
file a Bugzilla for this?
Vik and I are currently working with pressure on providing our
"reference integration" for CDO and GMF. Well it may start as a public
playground ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Christian W. Damus schrieb:
> Hi, Víctor, Stéphane,
>
> The TransactionalEditingDomain uses a TransactionChangeRecorder to
> record changes for rollback. This is how it usually detects that
> changes occur outside of a transaction context. The
> TransactionChangeRecorder acts like an EContentAdapter, propagating
> itself from the ResourceSet down into the contents of all of its
> resources.
>
> It sounds as though the change recorder is not being attached to the
> CDOResource, or perhaps not to its contents? Perhaps there is a
> problem in the dual nature of the CDOResource, which is a Resource
> *and* an EObject. What does it respond to an eContents() query? It
> could be that the TransactionChangeRecorder sees the resource as an
> EObject and tries to propagate itself to the eContents(), but there
> aren't any because it's actually a Resource that has getContents() ?
>
> Just speculating ...
>
> cW
>
> Víctor Roldán Betancort wrote:
>> Stéphane,
>>
>> I can't really tell you why you experience this, but I suspect it
>> could be related with something I experienced while working in the
>> CDO + GMF integration. The default CDOResoure implementation
>> (CDOResourceImpl) does implement
>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>> functionality of this "internal" (please note the quoting of
>> internal, as it seem EMF internals are freely used :P) is not present
>> in CDOResourceImpl. I recall some of the generated code from GMF was
>> heavily dependant on ResourceImpl internals.
>>
>> So unfortunately, many projects rely in the internals of
>> ResourceImpl, for instance, ModificationTrackingAdapter. It could be
>> related with what you've exposed. I would suggest you to make some
>> debugging (sometimes it's fun :P) and observe how does the
>> TransactionalEditingDomain manage XMIResources.
>>
>> There are other suspicious indicators on how EMF Transaction
>> "detects" resource changes:
>>
>> - Take a look at the Adapters installed in the Resource. ResourceImpl
>> carries some adapters CDOResourceImpl does not.
>> - workspace deltas fire change notifications. since CDOResource is
>> not in the workspace... no deltas...
>>
>> I'm afraid I can't say much more, it's a matter of debugging.
>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>> does not have, please let us know and we will try to implement it.
>>
>> HTH,
>> ViK.
>>
>>
>> Stéphane Fournier escribió:
>>> Hi,
>>>
>>> I am using the code of the CDO StandaloneManualExample class.
>>>
>>> I change some pieces of code to use a TransactionalEditingDomain (TED).
>>>
>>> First, I get the resourceSet from a TED then I open a CDO
>>> transaction with this resourceSet.
>>> I load an existing resource and add it a new object.
>>> Finally, I commit the transaction.
>>> That runs smoothly.
>>>
>>> That's weird, because if the resource is not a CDO one but an XMI
>>> one for instance, an exception is raised to warn model changes have
>>> to be done in a write transaction. This is a standard behavior when
>>> using TED.
>>>
>>> I was also expecting this behavior with a CDO resource.
>>>
>>> Is it a normal behavior for CDO resources ?
>>>
>>> Stephane.
>>>
>>>
>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427410 is a reply to message #427406] |
Tue, 17 February 2009 10:47 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Guys,
Comments below.
Eike Stepper wrote:
> Guys,
> As I said, I was kind of mentally occupied in the last time. Now I read
> this thread and the other one by Stephane which may be related. I have
> problems to get everything in the proper context.
> Stephane, would you mind telling me again:
> 1) What are you trying do achieve (integrate CDO with GMF or TED or...)?
My final goal is to build GMF editors relying on CDO resources. I did not
find a quick guide to achieve that (I'm waiting for the Victor's blog :)
), so I try to make the integration by steps.
The first one is to build a standard editor using a
TransactionalEditingDomain as far as I know GMF editors only work with
this kind of editing domain.
With the changes I made, I've almost reached this step (except the remote
exception see another post
http://www.eclipse.org/newsportal/article.php?id=39444&g roup=eclipse.tools.emf#39444).
> 2) Which version of CDO are you using therefor?
Since this morning, I use CDO 2.0.0 M5 with all available M5 EMF & EMFT
plug-ins. Before I used the 2.0.0M4 with all EMF plugins in M4.
> 3) Which problem did appear?
The problem was a different behavior between XMI resource and CDO resource
with a TED. With a XMI resource, all model changes have to be performed
within a write transaction. With a CDO one, no exception happens.
The problem is to mix these 2 transaction layers. And I have to use a TED
to be able to build GMF editors. Hence, I tried to solve that point first.
As you know, building a GMF editor is not straight forward the first time,
so I try keep it simple to avoid confusing problems coming from CDO/TED or
GMF / CDO, etc....
Another problem is related to the dual nature of a CDOResource. Indeed, in
the ChangeRecorder#notifychanged method, EObject case is handled before
Resource case. I switched the if else statements to make sure the
CDOResource will be handled as a Resource and not as an EObject. As
Christian mentioned it, it could raise performance issue.
As I said yesterday, this handling loads the resource content to attach
the resource adapters to contained objects.
Without that change, the TransationalChangeRecorder, involved in a TED,
was not notified of model changes, the editor does not get dirty and so
on...
> 4) Do you already suspect a reason for it?
> Christian, you asked "What does CDOResource respond to an eContents()
> query?".
> CDOResourceImpl does not override BasicEObjectImpl.eContents().
> As a consequence it returns the value of the only modeled containment
> feature "contents", i.e. the same as getContents().
> Stephane, you mentioned a mismatch between EMF and CDO featureID values.
> I guess that was not our intention. They should be identical. Did you
> file a Bugzilla for this?
Not yet, because I fixed the integer returned by this notification, but
only you can tell if the meaning between constants
(Resource.RESOURCE__IS_LOADED and EresourcePackage.CDO_RESOURCE__LOADED)
is the same. If so, I will file a bugzilla for sure.
> Vik and I are currently working with pressure on providing our
> "reference integration" for CDO and GMF. Well it may start as a public
> playground ;-)
I'm really interesting in helping you guys, because CDO looks promising
for my project but we need to have a CDO / GMF integration.
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
> Christian W. Damus schrieb:
>> Hi, Víctor, Stéphane,
>>
>> The TransactionalEditingDomain uses a TransactionChangeRecorder to
>> record changes for rollback. This is how it usually detects that
>> changes occur outside of a transaction context. The
>> TransactionChangeRecorder acts like an EContentAdapter, propagating
>> itself from the ResourceSet down into the contents of all of its
>> resources.
>>
>> It sounds as though the change recorder is not being attached to the
>> CDOResource, or perhaps not to its contents? Perhaps there is a
>> problem in the dual nature of the CDOResource, which is a Resource
>> *and* an EObject. What does it respond to an eContents() query? It
>> could be that the TransactionChangeRecorder sees the resource as an
>> EObject and tries to propagate itself to the eContents(), but there
>> aren't any because it's actually a Resource that has getContents() ?
>>
>> Just speculating ...
>>
>> cW
>>
>> Víctor Roldán Betancort wrote:
>>> Stéphane,
>>>
>>> I can't really tell you why you experience this, but I suspect it
>>> could be related with something I experienced while working in the
>>> CDO + GMF integration. The default CDOResoure implementation
>>> (CDOResourceImpl) does implement
>>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>>> functionality of this "internal" (please note the quoting of
>>> internal, as it seem EMF internals are freely used :P) is not present
>>> in CDOResourceImpl. I recall some of the generated code from GMF was
>>> heavily dependant on ResourceImpl internals.
>>>
>>> So unfortunately, many projects rely in the internals of
>>> ResourceImpl, for instance, ModificationTrackingAdapter. It could be
>>> related with what you've exposed. I would suggest you to make some
>>> debugging (sometimes it's fun :P) and observe how does the
>>> TransactionalEditingDomain manage XMIResources.
>>>
>>> There are other suspicious indicators on how EMF Transaction
>>> "detects" resource changes:
>>>
>>> - Take a look at the Adapters installed in the Resource. ResourceImpl
>>> carries some adapters CDOResourceImpl does not.
>>> - workspace deltas fire change notifications. since CDOResource is
>>> not in the workspace... no deltas...
>>>
>>> I'm afraid I can't say much more, it's a matter of debugging.
>>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>>> does not have, please let us know and we will try to implement it.
>>>
>>> HTH,
>>> ViK.
>>>
>>>
>>> Stéphane Fournier escribió:
>>>> Hi,
>>>>
>>>> I am using the code of the CDO StandaloneManualExample class.
>>>>
>>>> I change some pieces of code to use a TransactionalEditingDomain (TED).
>>>>
>>>> First, I get the resourceSet from a TED then I open a CDO
>>>> transaction with this resourceSet.
>>>> I load an existing resource and add it a new object.
>>>> Finally, I commit the transaction.
>>>> That runs smoothly.
>>>>
>>>> That's weird, because if the resource is not a CDO one but an XMI
>>>> one for instance, an exception is raised to warn model changes have
>>>> to be done in a write transaction. This is a standard behavior when
>>>> using TED.
>>>>
>>>> I was also expecting this behavior with a CDO resource.
>>>>
>>>> Is it a normal behavior for CDO resources ?
>>>>
>>>> Stephane.
>>>>
>>>>
>>>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427413 is a reply to message #427410] |
Tue, 17 February 2009 11:43 |
|
Stéphane,
Comments below...
Stéphane Fournier schrieb:
>> 1) What are you trying do achieve (integrate CDO with GMF or TED or...)?
>
> My final goal is to build GMF editors relying on CDO resources. I did
> not find a quick guide to achieve that (I'm waiting for the Victor's
> blog :) ), so I try to make the integration by steps.
Good idea ;-)
> The first one is to build a standard editor using a
> TransactionalEditingDomain as far as I know GMF editors only work with
> this kind of editing domain.
Not a good idea I suspect. But I don't know too much about all this GMF
stuff. Nevertheless (or even because of that) we decided to go topdown
and start with a plain GMF editor...
I'm at least not sure whether TEDs play an important role in this way,
so I'd prefer to look at their problems when it's necessary.
> With the changes I made, I've almost reached this step (except the
> remote exception see another post
> http://www.eclipse.org/newsportal/article.php?id=39444&g roup=eclipse.tools.emf#39444).
>
>
>> 2) Which version of CDO are you using therefor?
> Since this morning, I use CDO 2.0.0 M5 with all available M5 EMF &
> EMFT plug-ins. Before I used the 2.0.0M4 with all EMF plugins in M4.
Good.
>
>> 3) Which problem did appear?
> The problem was a different behavior between XMI resource and CDO
> resource with a TED. With a XMI resource, all model changes have to be
> performed within a write transaction. With a CDO one, no exception
> happens. The problem is to mix these 2 transaction layers. And I have
> to use a TED to be able to build GMF editors. Hence, I tried to solve
> that point first. As you know, building a GMF editor is not straight
> forward the first time, so I try keep it simple to avoid confusing
> problems coming from CDO/TED or GMF / CDO, etc....
As I said, I'd prefer not to mix TED problems with GMF problems so early.
Nevertheless one question pops into my mind: What is the locking
granularity of TEDs? EObjects or Resources?
If it's a resource granularity, then it's pretty clear why TED complains
about conflicts on resource level where CDO can resolve them on object
level...
>
>
> Another problem is related to the dual nature of a CDOResource.
> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
> handled before Resource case. I switched the if else statements to
> make sure the CDOResource will be handled as a Resource and not as an
> EObject. As Christian mentioned it, it could raise performance issue.
> As I said yesterday, this handling loads the resource content to
> attach the resource adapters to contained objects.
> Without that change, the TransationalChangeRecorder, involved in a
> TED, was not notified of model changes, the editor does not get dirty
> and so on...
All this stuff scares me a bit. The reason is that IMO ChangeRecorder
behaves like an EContentAdapter (no idea why it isn't).
While generally EContentAdapters _should_ work with CDO this undermines
demand-loading of containments, as offered by CDO.
We should keep in mind that we might have a problem here...
>
>
>> 4) Do you already suspect a reason for it?
>
>> Christian, you asked "What does CDOResource respond to an eContents()
>> query?".
>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>> As a consequence it returns the value of the only modeled containment
>> feature "contents", i.e. the same as getContents().
>
>> Stephane, you mentioned a mismatch between EMF and CDO featureID
>> values. I guess that was not our intention. They should be identical.
>> Did you file a Bugzilla for this?
>
> Not yet, because I fixed the integer returned by this notification,
> but only you can tell if the meaning between constants
> (Resource.RESOURCE__IS_LOADED and
> EresourcePackage.CDO_RESOURCE__LOADED) is the same. If so, I will file
> a bugzilla for sure.
Yes, they mean the same thing.
>
>
>> Vik and I are currently working with pressure on providing our
>> "reference integration" for CDO and GMF. Well it may start as a
>> public playground ;-)
>
> I'm really interesting in helping you guys, because CDO looks
> promising for my project but we need to have a CDO / GMF integration.
A prototype is not far now ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
>
>> Christian W. Damus schrieb:
>>> Hi, Víctor, Stéphane,
>>>
>>> The TransactionalEditingDomain uses a TransactionChangeRecorder to
>>> record changes for rollback. This is how it usually detects that
>>> changes occur outside of a transaction context. The
>>> TransactionChangeRecorder acts like an EContentAdapter, propagating
>>> itself from the ResourceSet down into the contents of all of its
>>> resources.
>>>
>>> It sounds as though the change recorder is not being attached to the
>>> CDOResource, or perhaps not to its contents? Perhaps there is a
>>> problem in the dual nature of the CDOResource, which is a Resource
>>> *and* an EObject. What does it respond to an eContents() query? It
>>> could be that the TransactionChangeRecorder sees the resource as an
>>> EObject and tries to propagate itself to the eContents(), but there
>>> aren't any because it's actually a Resource that has getContents() ?
>>>
>>> Just speculating ...
>>>
>>> cW
>>>
>>> Víctor Roldán Betancort wrote:
>>>> Stéphane,
>>>>
>>>> I can't really tell you why you experience this, but I suspect it
>>>> could be related with something I experienced while working in the
>>>> CDO + GMF integration. The default CDOResoure implementation
>>>> (CDOResourceImpl) does implement
>>>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>>>> functionality of this "internal" (please note the quoting of
>>>> internal, as it seem EMF internals are freely used :P) is not
>>>> present in CDOResourceImpl. I recall some of the generated code
>>>> from GMF was heavily dependant on ResourceImpl internals.
>>>>
>>>> So unfortunately, many projects rely in the internals of
>>>> ResourceImpl, for instance, ModificationTrackingAdapter. It could
>>>> be related with what you've exposed. I would suggest you to make
>>>> some debugging (sometimes it's fun :P) and observe how does the
>>>> TransactionalEditingDomain manage XMIResources.
>>>>
>>>> There are other suspicious indicators on how EMF Transaction
>>>> "detects" resource changes:
>>>>
>>>> - Take a look at the Adapters installed in the Resource.
>>>> ResourceImpl carries some adapters CDOResourceImpl does not.
>>>> - workspace deltas fire change notifications. since CDOResource is
>>>> not in the workspace... no deltas...
>>>>
>>>> I'm afraid I can't say much more, it's a matter of debugging.
>>>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>>>> does not have, please let us know and we will try to implement it.
>>>>
>>>> HTH,
>>>> ViK.
>>>>
>>>>
>>>> Stéphane Fournier escribió:
>>>>> Hi,
>>>>>
>>>>> I am using the code of the CDO StandaloneManualExample class.
>>>>>
>>>>> I change some pieces of code to use a TransactionalEditingDomain
>>>>> (TED).
>>>>>
>>>>> First, I get the resourceSet from a TED then I open a CDO
>>>>> transaction with this resourceSet.
>>>>> I load an existing resource and add it a new object.
>>>>> Finally, I commit the transaction.
>>>>> That runs smoothly.
>>>>>
>>>>> That's weird, because if the resource is not a CDO one but an XMI
>>>>> one for instance, an exception is raised to warn model changes
>>>>> have to be done in a write transaction. This is a standard
>>>>> behavior when using TED.
>>>>>
>>>>> I was also expecting this behavior with a CDO resource.
>>>>>
>>>>> Is it a normal behavior for CDO resources ?
>>>>>
>>>>> Stephane.
>>>>>
>>>>>
>>>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427415 is a reply to message #427413] |
Tue, 17 February 2009 16:04 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Eike,
Eike Stepper wrote:
> Stéphane,
> Comments below...
> Stéphane Fournier schrieb:
>>> 1) What are you trying do achieve (integrate CDO with GMF or TED or...)?
>>
>> My final goal is to build GMF editors relying on CDO resources. I did
>> not find a quick guide to achieve that (I'm waiting for the Victor's
>> blog :) ), so I try to make the integration by steps.
> Good idea ;-)
>> The first one is to build a standard editor using a
>> TransactionalEditingDomain as far as I know GMF editors only work with
>> this kind of editing domain.
> Not a good idea I suspect. But I don't know too much about all this GMF
> stuff. Nevertheless (or even because of that) we decided to go topdown
> and start with a plain GMF editor...
> I'm at least not sure whether TEDs play an important role in this way,
> so I'd prefer to look at their problems when it's necessary.
I agree with you. Nevertheless, you may face TransactionalEditingDomain
problems quickly as I did with a simple editor.
With a GMF editor, you have to cope with 2 models : the semantic one + the
UI diagram one. From my point of view, that increases the difficulties.
That's why I'd prefer to experience TED + CDO with a simple editor. To be
honest, It would be a great first step, if a EMF generated editor
(initially generated for XMI resource) can run properly with a CDO
resource using a TED rather than a standard EMF editing domain.
Now, I think our both approaches are good because they should meet
quickly. :)
>> With the changes I made, I've almost reached this step (except the
>> remote exception see another post
>>
http://www.eclipse.org/newsportal/article.php?id=39444&g roup=eclipse.tools.emf#39444).
>>
>>
>>> 2) Which version of CDO are you using therefor?
>> Since this morning, I use CDO 2.0.0 M5 with all available M5 EMF &
>> EMFT plug-ins. Before I used the 2.0.0M4 with all EMF plugins in M4.
> Good.
>>
>>> 3) Which problem did appear?
>> The problem was a different behavior between XMI resource and CDO
>> resource with a TED. With a XMI resource, all model changes have to be
>> performed within a write transaction. With a CDO one, no exception
>> happens. The problem is to mix these 2 transaction layers. And I have
>> to use a TED to be able to build GMF editors. Hence, I tried to solve
>> that point first. As you know, building a GMF editor is not straight
>> forward the first time, so I try keep it simple to avoid confusing
>> problems coming from CDO/TED or GMF / CDO, etc....
> As I said, I'd prefer not to mix TED problems with GMF problems so early.
> Nevertheless one question pops into my mind: What is the locking
> granularity of TEDs? EObjects or Resources?
> If it's a resource granularity, then it's pretty clear why TED complains
> about conflicts on resource level where CDO can resolve them on object
> level...
I think you are right in saying EMF transaction (in RW mode) locks at the
resource set level. But I'm not sure to understand what you mentioned :
then it's pretty clear why TED complains about conflicts on resource level
where CDO can resolve them on object level...
When using a TED, all loaded objects should have the
TransactionChangeRecorder (the one owned by the TED) in their eAdapters
list. Without that, the TED does not properly run i.e : model changes are
lost (not notified) from the TED point of view. That's the point I tried
to fix with suggested corrections.
If you do not experience that issue with a GMF editor, I will not
understand.
A editing domain (of course a TED one) has a major role in an editor (GMF
or not) regarding Edit operations...
>>
>>
>> Another problem is related to the dual nature of a CDOResource.
>> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
>> handled before Resource case. I switched the if else statements to
>> make sure the CDOResource will be handled as a Resource and not as an
>> EObject. As Christian mentioned it, it could raise performance issue.
>> As I said yesterday, this handling loads the resource content to
>> attach the resource adapters to contained objects.
>> Without that change, the TransationalChangeRecorder, involved in a
>> TED, was not notified of model changes, the editor does not get dirty
>> and so on...
> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
> behaves like an EContentAdapter (no idea why it isn't).
> While generally EContentAdapters _should_ work with CDO this undermines
> demand-loading of containments, as offered by CDO.
> We should keep in mind that we might have a problem here...
>>
>>
>>> 4) Do you already suspect a reason for it?
>>
>>> Christian, you asked "What does CDOResource respond to an eContents()
>>> query?".
>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>> As a consequence it returns the value of the only modeled containment
>>> feature "contents", i.e. the same as getContents().
>>
>>> Stephane, you mentioned a mismatch between EMF and CDO featureID
>>> values. I guess that was not our intention. They should be identical.
>>> Did you file a Bugzilla for this?
>>
>> Not yet, because I fixed the integer returned by this notification,
>> but only you can tell if the meaning between constants
>> (Resource.RESOURCE__IS_LOADED and
>> EresourcePackage.CDO_RESOURCE__LOADED) is the same. If so, I will file
>> a bugzilla for sure.
> Yes, they mean the same thing.
I've filed a bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136
>>
>>
>>> Vik and I are currently working with pressure on providing our
>>> "reference integration" for CDO and GMF. Well it may start as a
>>> public playground ;-)
>>
>> I'm really interesting in helping you guys, because CDO looks
>> promising for my project but we need to have a CDO / GMF integration.
> A prototype is not far now ;-)
Great news , would it be possible to test something ?
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
>>
>>> Cheers
>>> /Eike
>>
>>> ----
>>> http://thegordian.blogspot.com
>>
>>
>>
>>> Christian W. Damus schrieb:
>>>> Hi, Víctor, Stéphane,
>>>>
>>>> The TransactionalEditingDomain uses a TransactionChangeRecorder to
>>>> record changes for rollback. This is how it usually detects that
>>>> changes occur outside of a transaction context. The
>>>> TransactionChangeRecorder acts like an EContentAdapter, propagating
>>>> itself from the ResourceSet down into the contents of all of its
>>>> resources.
>>>>
>>>> It sounds as though the change recorder is not being attached to the
>>>> CDOResource, or perhaps not to its contents? Perhaps there is a
>>>> problem in the dual nature of the CDOResource, which is a Resource
>>>> *and* an EObject. What does it respond to an eContents() query? It
>>>> could be that the TransactionChangeRecorder sees the resource as an
>>>> EObject and tries to propagate itself to the eContents(), but there
>>>> aren't any because it's actually a Resource that has getContents() ?
>>>>
>>>> Just speculating ...
>>>>
>>>> cW
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>> Stéphane,
>>>>>
>>>>> I can't really tell you why you experience this, but I suspect it
>>>>> could be related with something I experienced while working in the
>>>>> CDO + GMF integration. The default CDOResoure implementation
>>>>> (CDOResourceImpl) does implement
>>>>> org.eclipse.emf.ecore.resource.Resource, but it *does not* extend
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl. So much of the
>>>>> functionality of this "internal" (please note the quoting of
>>>>> internal, as it seem EMF internals are freely used :P) is not
>>>>> present in CDOResourceImpl. I recall some of the generated code
>>>>> from GMF was heavily dependant on ResourceImpl internals.
>>>>>
>>>>> So unfortunately, many projects rely in the internals of
>>>>> ResourceImpl, for instance, ModificationTrackingAdapter. It could
>>>>> be related with what you've exposed. I would suggest you to make
>>>>> some debugging (sometimes it's fun :P) and observe how does the
>>>>> TransactionalEditingDomain manage XMIResources.
>>>>>
>>>>> There are other suspicious indicators on how EMF Transaction
>>>>> "detects" resource changes:
>>>>>
>>>>> - Take a look at the Adapters installed in the Resource.
>>>>> ResourceImpl carries some adapters CDOResourceImpl does not.
>>>>> - workspace deltas fire change notifications. since CDOResource is
>>>>> not in the workspace... no deltas...
>>>>>
>>>>> I'm afraid I can't say much more, it's a matter of debugging.
>>>>> If you find some behavior in "ResourceImpl" that "CDOResourceImpl"
>>>>> does not have, please let us know and we will try to implement it.
>>>>>
>>>>> HTH,
>>>>> ViK.
>>>>>
>>>>>
>>>>> Stéphane Fournier escribió:
>>>>>> Hi,
>>>>>>
>>>>>> I am using the code of the CDO StandaloneManualExample class.
>>>>>>
>>>>>> I change some pieces of code to use a TransactionalEditingDomain
>>>>>> (TED).
>>>>>>
>>>>>> First, I get the resourceSet from a TED then I open a CDO
>>>>>> transaction with this resourceSet.
>>>>>> I load an existing resource and add it a new object.
>>>>>> Finally, I commit the transaction.
>>>>>> That runs smoothly.
>>>>>>
>>>>>> That's weird, because if the resource is not a CDO one but an XMI
>>>>>> one for instance, an exception is raised to warn model changes
>>>>>> have to be done in a write transaction. This is a standard
>>>>>> behavior when using TED.
>>>>>>
>>>>>> I was also expecting this behavior with a CDO resource.
>>>>>>
>>>>>> Is it a normal behavior for CDO resources ?
>>>>>>
>>>>>> Stephane.
>>>>>>
>>>>>>
>>>>>>
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427428 is a reply to message #427413] |
Tue, 17 February 2009 19:27 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Eike,
Just a few answers to some of your questions in-line, below.
Cheers,
Christian
Eike Stepper wrote:
-----8<-----
> As I said, I'd prefer not to mix TED problems with GMF problems so early.
As I think Stéphane also mentioned, it is likely that most of your GMF
problems will boil down to the TED, anyway. :-)
> Nevertheless one question pops into my mind: What is the locking
> granularity of TEDs? EObjects or Resources?
The ResourceSet. As the TED is a layer on top of EMF, and did not take
the deep integration approach as CDO has done, there was no means to
effectively control concurrent access at the object level or even the
resource level. Certainly, we don't have true transactions in the usual
sense of the word, which is where CDO derives most of the benefit of its
EObject integration.
> If it's a resource granularity, then it's pretty clear why TED complains
> about conflicts on resource level where CDO can resolve them on object
> level...
>
>>
>>
>> Another problem is related to the dual nature of a CDOResource.
>> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
>> handled before Resource case. I switched the if else statements to
>> make sure the CDOResource will be handled as a Resource and not as an
>> EObject. As Christian mentioned it, it could raise performance issue.
>> As I said yesterday, this handling loads the resource content to
>> attach the resource adapters to contained objects.
>> Without that change, the TransationalChangeRecorder, involved in a
>> TED, was not notified of model changes, the editor does not get dirty
>> and so on...
> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
> behaves like an EContentAdapter (no idea why it isn't).
EContentAdapters remove themselves from objects that are detached from
the content tree, because they are considered no longer to be of
interest. However, ChangeRecorders do continue to listen to detached
objects because they need to record any changes that may be done while
an object is unattached, so that the ChangeDescription would be able to
undo them (and undo the detachment of the object) coherently.
> While generally EContentAdapters _should_ work with CDO this undermines
> demand-loading of containments, as offered by CDO.
> We should keep in mind that we might have a problem here...
Oh, yes. I suspect that you will need more control over how and when
objects become available to the change recorder so that it does not
cause the entire repository to be loaded!
>
>>
>>
>>> 4) Do you already suspect a reason for it?
>>
>>> Christian, you asked "What does CDOResource respond to an eContents()
>>> query?".
>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>> As a consequence it returns the value of the only modeled containment
>>> feature "contents", i.e. the same as getContents().
But, Resource doesn't define features: the only model representation of
it is the EResource data type, which being an EDataType, doesn't have
features. So, I would expect that eContents() actually always returns
an empty list.
-----8<-----
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427429 is a reply to message #427428] |
Tue, 17 February 2009 19:48 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Christian,
I agree with the eContents comments. For an EObject x, eContents()
should only return objects y for which y.eContainer() returns x. The
question then is what containment feature of x hold y, i.e, what's
y.eContainmentFeature()...
Christian W. Damus wrote:
> Hi, Eike,
>
> Just a few answers to some of your questions in-line, below.
>
> Cheers,
>
> Christian
>
>
> Eike Stepper wrote:
>
> -----8<-----
>
>> As I said, I'd prefer not to mix TED problems with GMF problems so
>> early.
>
> As I think Stéphane also mentioned, it is likely that most of your GMF
> problems will boil down to the TED, anyway. :-)
>
>
>> Nevertheless one question pops into my mind: What is the locking
>> granularity of TEDs? EObjects or Resources?
>
> The ResourceSet. As the TED is a layer on top of EMF, and did not
> take the deep integration approach as CDO has done, there was no means
> to effectively control concurrent access at the object level or even
> the resource level. Certainly, we don't have true transactions in the
> usual sense of the word, which is where CDO derives most of the
> benefit of its EObject integration.
>
>
>> If it's a resource granularity, then it's pretty clear why TED
>> complains about conflicts on resource level where CDO can resolve
>> them on object level...
>>
>>>
>>>
>>> Another problem is related to the dual nature of a CDOResource.
>>> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
>>> handled before Resource case. I switched the if else statements to
>>> make sure the CDOResource will be handled as a Resource and not as
>>> an EObject. As Christian mentioned it, it could raise performance
>>> issue.
>>> As I said yesterday, this handling loads the resource content to
>>> attach the resource adapters to contained objects.
>>> Without that change, the TransationalChangeRecorder, involved in a
>>> TED, was not notified of model changes, the editor does not get
>>> dirty and so on...
>> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
>> behaves like an EContentAdapter (no idea why it isn't).
>
> EContentAdapters remove themselves from objects that are detached from
> the content tree, because they are considered no longer to be of
> interest. However, ChangeRecorders do continue to listen to detached
> objects because they need to record any changes that may be done while
> an object is unattached, so that the ChangeDescription would be able
> to undo them (and undo the detachment of the object) coherently.
>
>
>> While generally EContentAdapters _should_ work with CDO this
>> undermines demand-loading of containments, as offered by CDO.
>> We should keep in mind that we might have a problem here...
>
> Oh, yes. I suspect that you will need more control over how and when
> objects become available to the change recorder so that it does not
> cause the entire repository to be loaded!
>
>
>>
>>>
>>>
>>>> 4) Do you already suspect a reason for it?
>>>
>>>> Christian, you asked "What does CDOResource respond to an
>>>> eContents() query?".
>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>> As a consequence it returns the value of the only modeled
>>>> containment feature "contents", i.e. the same as getContents().
>
> But, Resource doesn't define features: the only model representation
> of it is the EResource data type, which being an EDataType, doesn't
> have features. So, I would expect that eContents() actually always
> returns an empty list.
>
>
> -----8<-----
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427432 is a reply to message #427428] |
Tue, 17 February 2009 21:52 |
|
Hi Christian,
Again inline...
Christian W. Damus schrieb:
> -----8<-----
>
>> As I said, I'd prefer not to mix TED problems with GMF problems so
>> early.
>
> As I think Stéphane also mentioned, it is likely that most of your GMF
> problems will boil down to the TED, anyway. :-)
That was clear to me ;-)
And this way or that way, sooner or later, the TED problem with CDO will
pop up again, here.
But I still tend to think that, even if we manage (and I'm sure we
could) to have two different transaction layers on top of each other,
that this is not an ideal solution. It's just that I think that, if you
want CDO at the bottom (for the other functionailty, not included in EMF
Transations) and GMF at the top of your technology stack, there is
really no reason to have a TED in between, other maybe that GMF is
currently designed to have it there. I think, if GMF needs
transactionailty and there are multiple Eclipse technologies available
to fulfill this demand and there is community demand for more pluggable
integration of orthogonal functionality, then clearly GMF should open up
this part and give the user the choice. Finally that's the main reason
why I (for myself) wanted to go top down, because only then I can see
how and where exactly this strong binding to EMF Transaction is in GMF
and how we could try to abstract these dependencies away. Whether GMF
would consider patches in this area is written on a different page though :P
>
>
>> Nevertheless one question pops into my mind: What is the locking
>> granularity of TEDs? EObjects or Resources?
>
> The ResourceSet. As the TED is a layer on top of EMF, and did not
> take the deep integration approach as CDO has done, there was no means
> to effectively control concurrent access at the object level or even
> the resource level. Certainly, we don't have true transactions in the
> usual sense of the word, which is where CDO derives most of the
> benefit of its EObject integration.
Then, to answer Stephanes question why a TED raises an exception and CDO
not, I think this might be the reason:
1) Transaction A modifies Object a in resource X
2) Transaction B modifies Object b in the same resource X (same
instance, i.e. same resource set)
A TED would complain because it's clear that these two changes would
result in a file save conflict. CDO on the other hand would not
recognize any critical situation (if A != B) because CDO transactions
collect changes in form of deltas and commits all the deltas to the
repository in the end. No conflict, no exception, no problem ;-)
>
>
>> If it's a resource granularity, then it's pretty clear why TED
>> complains about conflicts on resource level where CDO can resolve
>> them on object level...
>>
>>>
>>>
>>> Another problem is related to the dual nature of a CDOResource.
>>> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
>>> handled before Resource case. I switched the if else statements to
>>> make sure the CDOResource will be handled as a Resource and not as
>>> an EObject. As Christian mentioned it, it could raise performance
>>> issue.
>>> As I said yesterday, this handling loads the resource content to
>>> attach the resource adapters to contained objects.
>>> Without that change, the TransationalChangeRecorder, involved in a
>>> TED, was not notified of model changes, the editor does not get
>>> dirty and so on...
>> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
>> behaves like an EContentAdapter (no idea why it isn't).
>
> EContentAdapters remove themselves from objects that are detached from
> the content tree, because they are considered no longer to be of
> interest. However, ChangeRecorders do continue to listen to detached
> objects because they need to record any changes that may be done while
> an object is unattached, so that the ChangeDescription would be able
> to undo them (and undo the detachment of the object) coherently.
I see, I didn't consider that undo brings additional requirements that
play no role in mere transactionality. On the other hand (to return to
my initial motivation) for undo we just need a command stack (or a
change recorder) and not a TED. At least not if CDO is underneath anyway.
>
>
>> While generally EContentAdapters _should_ work with CDO this
>> undermines demand-loading of containments, as offered by CDO.
>> We should keep in mind that we might have a problem here...
>
> Oh, yes. I suspect that you will need more control over how and when
> objects become available to the change recorder so that it does not
> cause the entire repository to be loaded!
Yes, in the end the required functionality "I want to see all change"
and not "I want to have my whole containment tree adapted (and thereby
loaded)". Formerly, in the ancient times of XML file persistence :P ,
that might have boiled down to the same thing. But with the availability
of containment demand-loading (I think Teneo has similar
characteristics, but I'm not sure), this implicit equality should be
generally re-considered. Sure, it's a problem that all this code is out
there that builds on this assumption...
>
>
>>
>>>
>>>
>>>> 4) Do you already suspect a reason for it?
>>>
>>>> Christian, you asked "What does CDOResource respond to an
>>>> eContents() query?".
>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>> As a consequence it returns the value of the only modeled
>>>> containment feature "contents", i.e. the same as getContents().
>
> But, Resource doesn't define features: the only model representation
> of it is the EResource data type, which being an EDataType, doesn't
> have features. So, I would expect that eContents() actually always
> returns an empty list.
I think this argument is odd ;-)
Would you also argue "EObject doesn't define annotations. So, I would
expect that EClass.getEAnnotations() actually always returns an empty
list."?
And I would say, the absence of a concept in Ecore is usually no ban
from other models.
Apart from the fact that one concept is modeled (EObject) and one is not
(Resource), I still can't see the semantic differences between
eContents() and getContents().
The only effect of making this difference explicit is increased effort
to implement the same functionality (notification, containment, ...).
Since we have to consider persistence, transactionality and others as
well, our effort would be magnitudes higher.
I decided to take a different approach and if you look into the
implementation of CDOResourceImpl, where you might expect large amounts
of integration code, you'll find only a handful overrides to bring
together what belongs together (eContents and contents).
But, back to the initial question, a CDOResource does not return an
empty list for eContents(), if getContents() is not empty.
I even can't point you to code in CDOResourceImpl where this becomes
evident, because there is no such code.
getContents() is is a normal containment feature of CDOResource and as a
consequence it is considered a valid contributor to eContents() by
BasicEObjectImpl ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427433 is a reply to message #427429] |
Tue, 17 February 2009 21:57 |
|
Ed Merks schrieb:
> Christian,
>
> I agree with the eContents comments. For an EObject x, eContents()
> should only return objects y for which y.eContainer() returns x. The
> question then is what containment feature of x hold y, i.e, what's
> y.eContainmentFeature()...
I tested it, it's null.
Does that indicate a problem?
Cheers
/Eike
----
http://thegordian.blogspot.com
>
>
> Christian W. Damus wrote:
>> Hi, Eike,
>>
>> Just a few answers to some of your questions in-line, below.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Eike Stepper wrote:
>>
>> -----8<-----
>>
>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>> early.
>>
>> As I think Stéphane also mentioned, it is likely that most of your
>> GMF problems will boil down to the TED, anyway. :-)
>>
>>
>>> Nevertheless one question pops into my mind: What is the locking
>>> granularity of TEDs? EObjects or Resources?
>>
>> The ResourceSet. As the TED is a layer on top of EMF, and did not
>> take the deep integration approach as CDO has done, there was no
>> means to effectively control concurrent access at the object level or
>> even the resource level. Certainly, we don't have true transactions
>> in the usual sense of the word, which is where CDO derives most of
>> the benefit of its EObject integration.
>>
>>
>>> If it's a resource granularity, then it's pretty clear why TED
>>> complains about conflicts on resource level where CDO can resolve
>>> them on object level...
>>>
>>>>
>>>>
>>>> Another problem is related to the dual nature of a CDOResource.
>>>> Indeed, in the ChangeRecorder#notifychanged method, EObject case is
>>>> handled before Resource case. I switched the if else statements to
>>>> make sure the CDOResource will be handled as a Resource and not as
>>>> an EObject. As Christian mentioned it, it could raise performance
>>>> issue.
>>>> As I said yesterday, this handling loads the resource content to
>>>> attach the resource adapters to contained objects.
>>>> Without that change, the TransationalChangeRecorder, involved in a
>>>> TED, was not notified of model changes, the editor does not get
>>>> dirty and so on...
>>> All this stuff scares me a bit. The reason is that IMO
>>> ChangeRecorder behaves like an EContentAdapter (no idea why it isn't).
>>
>> EContentAdapters remove themselves from objects that are detached
>> from the content tree, because they are considered no longer to be of
>> interest. However, ChangeRecorders do continue to listen to detached
>> objects because they need to record any changes that may be done
>> while an object is unattached, so that the ChangeDescription would be
>> able to undo them (and undo the detachment of the object) coherently.
>>
>>
>>> While generally EContentAdapters _should_ work with CDO this
>>> undermines demand-loading of containments, as offered by CDO.
>>> We should keep in mind that we might have a problem here...
>>
>> Oh, yes. I suspect that you will need more control over how and when
>> objects become available to the change recorder so that it does not
>> cause the entire repository to be loaded!
>>
>>
>>>
>>>>
>>>>
>>>>> 4) Do you already suspect a reason for it?
>>>>
>>>>> Christian, you asked "What does CDOResource respond to an
>>>>> eContents() query?".
>>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>>> As a consequence it returns the value of the only modeled
>>>>> containment feature "contents", i.e. the same as getContents().
>>
>> But, Resource doesn't define features: the only model representation
>> of it is the EResource data type, which being an EDataType, doesn't
>> have features. So, I would expect that eContents() actually always
>> returns an empty list.
>>
>>
>> -----8<-----
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427437 is a reply to message #427432] |
Wed, 18 February 2009 01:07 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Eike,
Let's see whether you can find my replies to your replies in the
increasing morass of text. :-)
cW
Eike Stepper wrote:
> Hi Christian,
>
> Again inline...
>
>
> Christian W. Damus schrieb:
>> -----8<-----
>>
>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>> early.
>>
>> As I think Stéphane also mentioned, it is likely that most of your GMF
>> problems will boil down to the TED, anyway. :-)
> That was clear to me ;-)
> And this way or that way, sooner or later, the TED problem with CDO will
> pop up again, here.
>
> But I still tend to think that, even if we manage (and I'm sure we
> could) to have two different transaction layers on top of each other,
> that this is not an ideal solution. It's just that I think that, if you
> want CDO at the bottom (for the other functionailty, not included in EMF
> Transations) and GMF at the top of your technology stack, there is
> really no reason to have a TED in between, other maybe that GMF is
> currently designed to have it there. I think, if GMF needs
Yes, that's a key point: the EMF Transaction component (excluding the
org.eclipse.emf.workspace* plug-ins) originated as a re-design, to
similar (and a few additional) requirements, of a part of the original
GMF run-time contribution. The name "Transaction" derives from one of
the key types in the API which, ironically, ordinary client applications
never have to deal with.
Thus, the dependencies in GMF on this layer can be expected to be quite
extensive. My hope is that it would be possible to implement a
CDOTransactionalEditingDomain that implements the API contract of the
EMF Transaction component in CDO terms. This probably wouldn't reuse
much of the default implementation, but there would probably be
assumptions within the Transaction API that need to be addressed to make
it work ...
> transactionailty and there are multiple Eclipse technologies available
> to fulfill this demand and there is community demand for more pluggable
> integration of orthogonal functionality, then clearly GMF should open up
> this part and give the user the choice. Finally that's the main reason
> why I (for myself) wanted to go top down, because only then I can see
> how and where exactly this strong binding to EMF Transaction is in GMF
> and how we could try to abstract these dependencies away. Whether GMF
> would consider patches in this area is written on a different page
> though :P
>
>>
>>
>>> Nevertheless one question pops into my mind: What is the locking
>>> granularity of TEDs? EObjects or Resources?
>>
>> The ResourceSet. As the TED is a layer on top of EMF, and did not
>> take the deep integration approach as CDO has done, there was no means
>> to effectively control concurrent access at the object level or even
>> the resource level. Certainly, we don't have true transactions in the
>> usual sense of the word, which is where CDO derives most of the
>> benefit of its EObject integration.
> Then, to answer Stephanes question why a TED raises an exception and CDO
> not, I think this might be the reason:
>
> 1) Transaction A modifies Object a in resource X
> 2) Transaction B modifies Object b in the same resource X (same
> instance, i.e. same resource set)
>
> A TED would complain because it's clear that these two changes would
> result in a file save conflict. CDO on the other hand would not
It's not as much about file-save conflicts as it is about concurrent
access to an EMF run-time system that is inherently not thread-safe. In
CDO, clients A and B effectively see different states of the same model
until they commit, after which point they each the changes that the
other mode. I'm assuming that one of them will not successfully commit
if it has feature-level conflicts with the other.
The EMF Transaction component has only one view of the resource set
contents to offer to all clients, so it implements this coarse-grained
locking to protect them from getting confused by dirty reads, concurrent
modification exceptions, etc.
> recognize any critical situation (if A != B) because CDO transactions
> collect changes in form of deltas and commits all the deltas to the
> repository in the end. No conflict, no exception, no problem ;-)
Yes. A fully transactional environment, which EMF Transaction is not :-P
>>> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
>>> behaves like an EContentAdapter (no idea why it isn't).
>>
>> EContentAdapters remove themselves from objects that are detached from
>> the content tree, because they are considered no longer to be of
>> interest. However, ChangeRecorders do continue to listen to detached
>> objects because they need to record any changes that may be done while
>> an object is unattached, so that the ChangeDescription would be able
>> to undo them (and undo the detachment of the object) coherently.
> I see, I didn't consider that undo brings additional requirements that
> play no role in mere transactionality. On the other hand (to return to
No, it does play a role in transactionality. One of the features of the
EMF Transaction component is automatic validation of transactions
(change-sets) with the potential that, if validation fails, the changes
are rolled back to restore the data to a safe state. The mechanism
employed in roll-back recording is the (Transaction)ChangeRecorder.
> my initial motivation) for undo we just need a command stack (or a
> change recorder) and not a TED. At least not if CDO is underneath anyway.
It happens that the change recorder also facilitates a convenient means
to implement undo/redo, using change descriptions that we recorded for
data integrity purposes, anyway. We make it easy to build the
command-stack based on the changes that are recorded for roll-back.
>>
>>
>>> While generally EContentAdapters _should_ work with CDO this
>>> undermines demand-loading of containments, as offered by CDO.
>>> We should keep in mind that we might have a problem here...
>>
>> Oh, yes. I suspect that you will need more control over how and when
>> objects become available to the change recorder so that it does not
>> cause the entire repository to be loaded!
> Yes, in the end the required functionality "I want to see all change"
> and not "I want to have my whole containment tree adapted (and thereby
> loaded)". Formerly, in the ancient times of XML file persistence :P ,
> that might have boiled down to the same thing. But with the availability
> of containment demand-loading (I think Teneo has similar
> characteristics, but I'm not sure), this implicit equality should be
> generally re-considered. Sure, it's a problem that all this code is out
> there that builds on this assumption...
Oh, there are all kinds of applications that assume some
long-since-eliminated limitations of EMF. Many are still trying to
catch up to the reality of cross-resource-containment, and that was
released years ago!
>>
>>
>>>
>>>>
>>>>
>>>>> 4) Do you already suspect a reason for it?
>>>>
>>>>> Christian, you asked "What does CDOResource respond to an
>>>>> eContents() query?".
>>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>>> As a consequence it returns the value of the only modeled
>>>>> containment feature "contents", i.e. the same as getContents().
>>
>> But, Resource doesn't define features: the only model representation
>> of it is the EResource data type, which being an EDataType, doesn't
>> have features. So, I would expect that eContents() actually always
>> returns an empty list.
> I think this argument is odd ;-)
> Would you also argue "EObject doesn't define annotations. So, I would
> expect that EClass.getEAnnotations() actually always returns an empty
> list."?
What I meant wasn't that I would expect any resource that is an EObject
to have no eContents(). Only that I would expect an EObject that has no
containment references not to return anything from eContents(). For
some reason, I assumed that CDOResource didn't model the contents-list
as a containment reference. If it is a containment reference that
happens to generate a setter named getContents that corresponds to the
Resource API, then of course it will provide eContents()! :-)
> And I would say, the absence of a concept in Ecore is usually no ban
> from other models.
> Apart from the fact that one concept is modeled (EObject) and one is not
> (Resource), I still can't see the semantic differences between
> eContents() and getContents().
Well, as Ed indicated, it is generally expected that all objects in the
eContents() list answer the container as their eContainer(). Do the
roots of a CDOResource answer their eDirectResource() as their
eContainer()? And what does a CDOResource answer to the eResource()
query? Itself?
Resources are outside of the logical model/data that comprises the
EObject tree. They assign a URI to an extent of objects for location
and persistence purposes, but otherwise are meaningless. Objects in one
resource can be moved to another and still mean exactly the same as
before. A model can be collected under one resource or many; it doesn't
matter to the semantics.
> The only effect of making this difference explicit is increased effort
> to implement the same functionality (notification, containment, ...).
> Since we have to consider persistence, transactionality and others as
> well, our effort would be magnitudes higher.
Maybe the effort would be worthwhile if it avoids confusion of semantics
that applications expect? I don't know whether it is a practical issue
for existing applications ... I suspect that most of the interactions
with resources are based on the a priori knowledge that the object in
hand is to be treated as a Resource and not as something else.
> I decided to take a different approach and if you look into the
> implementation of CDOResourceImpl, where you might expect large amounts
> of integration code, you'll find only a handful overrides to bring
> together what belongs together (eContents and contents).
Well, if you think they belong together ... I'm not convinced that I
should consider resources as elements of my model. :-)
> But, back to the initial question, a CDOResource does not return an
> empty list for eContents(), if getContents() is not empty.
> I even can't point you to code in CDOResourceImpl where this becomes
> evident, because there is no such code.
> getContents() is is a normal containment feature of CDOResource and as a
> consequence it is considered a valid contributor to eContents() by
> BasicEObjectImpl ;-)
Right, because you modeled contents as a containment reference of the
CDOResource EClass. That's the bit that wasn't clear to me, before, and
makes all the difference!
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427440 is a reply to message #427437] |
Wed, 18 February 2009 07:12 |
|
This is a multi-part message in MIME format.
--------------080802020000030205060803
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Christian,
With Thunderbird it's easy ;-)
I see it like this:
No idea anymore if I needed to install a plugin for that.
More comments below...
Christian W. Damus schrieb:
> Yes, that's a key point: the EMF Transaction component (excluding the
> org.eclipse.emf.workspace* plug-ins) originated as a re-design, to
> similar (and a few additional) requirements, of a part of the original
> GMF run-time contribution. The name "Transaction" derives from one of
> the key types in the API which, ironically, ordinary client
> applications never have to deal with.
I see.
> Thus, the dependencies in GMF on this layer can be expected to be
> quite extensive. My hope is that it would be possible to implement a
> CDOTransactionalEditingDomain that implements the API contract of the
> EMF Transaction component in CDO terms. This probably wouldn't reuse
> much of the default implementation, but there would probably be
> assumptions within the Transaction API that need to be addressed to
> make it work ...
That's a good idea!
We'll try this as soon as it becomes necessary.
I'm sure we'll pull you in again, then.
> It's not as much about file-save conflicts as it is about concurrent
> access to an EMF run-time system that is inherently not thread-safe.
> In CDO, clients A and B effectively see different states of the same
> model until they commit, after which point they each the changes that
> the other mode. I'm assuming that one of them will not successfully
> commit if it has feature-level conflicts with the other.
Well, by default CDO recognizes conflicts on object level by comparing
versions.
Recently we introduced pluggable conflict resolution strategies, with
feature level auto merging as a default implementation.
> The EMF Transaction component has only one view of the resource set
> contents to offer to all clients, so it implements this coarse-grained
> locking to protect them from getting confused by dirty reads,
> concurrent modification exceptions, etc.
I see.
>
>> And I would say, the absence of a concept in Ecore is usually no ban
>> from other models.
>> Apart from the fact that one concept is modeled (EObject) and one is
>> not (Resource), I still can't see the semantic differences between
>> eContents() and getContents().
> Well, as Ed indicated, it is generally expected that all objects in
> the eContents() list answer the container as their eContainer(). Do
> the roots of a CDOResource answer their eDirectResource() as their
> eContainer()? And what does a CDOResource answer to the eResource()
> query? Itself?
>
> Resources are outside of the logical model/data that comprises the
> EObject tree. They assign a URI to an extent of objects for location
> and persistence purposes, but otherwise are meaningless. Objects in
> one resource can be moved to another and still mean exactly the same
> as before. A model can be collected under one resource or many; it
> doesn't matter to the semantics.
I understand all this (at least I think) ;-)
If you want to understand my point of view I suggest that, for a moment,
you forget about almost everything that you know about resources and
their implications as postulated by EMF. Imagine all your object graph
resides in a box (a model repository) without a file system that you can
browse with an ordinary operating system tool (e.g. Windows Explorer,
....). You can access each and every object, load and unload it without
thinking about containment and partitioning into multiple resources.
Think about your business model. The only thing that you need (ignoring
query facilities) is a kind of entry object to start navigation from.
For this purpose CDO provides generic _named objects_ and calls them
CDOResource. They are just ordinary objects with a name (URI). Their
name and their contents list are just normal persistent features (that
need to be managed by the framework). Modification creates new revisions
and in a database these are just normal rows. In the absence of standard
operating tools to browse these resources we recently invented the
concept of a CDOResourceFolder. It shares the same abtract base class
CDOResourceNode with CDOResource (simple composite tree pattern in
analogy to IResource et al). The top-level resource nodes are contained
by a special root resource which is mostly invisible. With all this in
place we can easily provide our own browser of the "repository file system":
I think in the context of such a repository it makes sense to not focus
on the (granted: existing) differences between objects and resources but
rather on their similarities. I admit that, since EMF settled the
standard, this can eventually lead to confusion in existing frameworks
and applications. We need to look very carefully at every problem that
is brought to our attention to see if we can fix a bug in CDO or if it
is a good reason to change our general point of of view in this regard.
> Maybe the effort would be worthwhile if it avoids confusion of
> semantics that applications expect?
Absolutely right. As I mentioned, interoperability has priority.
> I don't know whether it is a practical issue for existing applications
> ... I suspect that most of the interactions with resources are based
> on the a priori knowledge that the object in hand is to be treated as
> a Resource and not as something else.
Probably you are right here.
Cheers
/Eike
----
http://thegordian.blogspot.com
--------------080802020000030205060803
Content-Type: multipart/related;
boundary="------------030504050103080402070301"
--------------030504050103080402070301
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Christian,<br>
<br>
With Thunderbird it's easy ;-)<br>
I see it like this:<br>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427449 is a reply to message #427433] |
Wed, 18 February 2009 11:47 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090902090207050107090608
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Eike,
In all other cases, the eContainer of an object's eContents will be that
same object. That's because this description of what eContents returns
is generally expected to be true:
This will be the list of |EObject
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EObject >|s
determined by the |contents
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eGet%E2%98%82EStructuralFeature >|
of the |containment features
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EClass%E2%98%82getEAllContainments >|
of this object's |meta class
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eClass >|.
So while it looks appealing and reasonable for eContents() to return
getContents(), it's arguably inconsistent with the definition of what
should be returned. And while you might be tempted to define a
containment reference for your resource meta class, that will result in
different inconsistencies and won't allow you to support cross resource
containment.
Of course you ignored this comment in Resource.java too, which is why
there's an issue in the first place. :-P
Clients must extend the default |implementation
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore.resource%7BResource.java%E2%98%83Resource%E2 %98%82org.eclipse.emf.ecore.resource.impl.ResourceImpl >|,
or one of its derived classes, since methods can and will be added
to this API.
I know even of cases that ignore this in EObject (for no apparent
reason!). Fortunately you didn't do that. :-P
Implementations of EObject should extend |BasicEObjectImpl
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%E2%98%82org.e clipse.emf.ecore.impl.BasicEObjectImpl >|
or one of its derived classes because methods can and will be added
to this API.
Eike Stepper wrote:
> Ed Merks schrieb:
>> Christian,
>>
>> I agree with the eContents comments. For an EObject x, eContents()
>> should only return objects y for which y.eContainer() returns x. The
>> question then is what containment feature of x hold y, i.e, what's
>> y.eContainmentFeature()...
> I tested it, it's null.
> Does that indicate a problem?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Eike,
>>>
>>> Just a few answers to some of your questions in-line, below.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Eike Stepper wrote:
>>>
>>> -----8<-----
>>>
>>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>>> early.
>>>
>>> As I think St
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427460 is a reply to message #427449] |
Wed, 18 February 2009 13:20 |
|
This is a multi-part message in MIME format.
--------------070602030706070001020103
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Ed,
Oh, this darn old story ;-(
And I can't claim you are wrong.
I'm pretty sure you understand my semantic point of view, ignoring the
existing contracts of EMF.
And I'm still willing to re-consider my current approach, but it's a
question of man power.
If we had more contributors and committers we could address more issues
like this...
More comments inline...
Ed Merks schrieb:
> Eike,
>
> In all other cases, the eContainer of an object's eContents will be
> that same object. That's because this description of what eContents
> returns is generally expected to be true:
>
> This will be the list of |EObject
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EObject >|s
> determined by the |contents
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eGet%E2%98%82EStructuralFeature >|
> of the |containment features
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EClass%E2%98%82getEAllContainments >|
> of this object's |meta class
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eClass >|.
>
> So while it looks appealing and reasonable for eContents() to return
> getContents(), it's arguably inconsistent with the definition of what
> should be returned. And while you might be tempted to define a
> containment reference for your resource meta class, that will result
> in different inconsistencies and won't allow you to support cross
> resource containment.
I'm sure we do!
I'd have to ask Simon, how exactly ;-)
This (and my call with Axel U.) reminds me that we have several such
"misalignments".
Another one is our interpretation of Resource.save(), which, in a
transactional system, can not simply store everything in that resource
and nothing from other resources.
Admittedly there is a more conceptual reason than in our Resource /
EObject story (which is more caused by my laziness).
>
> Of course you ignored this comment in Resource.java too, which is why
> there's an issue in the first place. :-P
>
> Clients must extend the default |implementation
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore.resource%7BResource.java%E2%98%83Resource%E2 %98%82org.eclipse.emf.ecore.resource.impl.ResourceImpl >|,
> or one of its derived classes, since methods can and will be added
> to this API.
>
Some time ago I asked to change the JavaDoc :P
Not to change the directive, but to change the explanation.
Instable APIs are stuff an extender could consider to live with. It only
causes effort to stay in sync.
I find it more important for extenders to give reliable guarantees about
the framework's usage of the respective interface.
Will the framework explicitely downcast instances to the Impl type or
will it not (never).
This piece of information definitely influences a decision that has to
be made.
The other one is nice to know.
> I know even of cases that ignore this in EObject (for no apparent
> reason!). Fortunately you didn't do that. :-P
>
> Implementations of EObject should extend |BasicEObjectImpl
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%E2%98%82org.e clipse.emf.ecore.impl.BasicEObjectImpl >|
> or one of its derived classes because methods can and will be
> added to this API.
>
I didn't even know that :P
Cheers
/Eike
----
http://thegordian.blogspot.com
>
>
> Eike Stepper wrote:
>> Ed Merks schrieb:
>>> Christian,
>>>
>>> I agree with the eContents comments. For an EObject x, eContents()
>>> should only return objects y for which y.eContainer() returns x.
>>> The question then is what containment feature of x hold y, i.e,
>>> what's y.eContainmentFeature()...
>> I tested it, it's null.
>> Does that indicate a problem?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Eike,
>>>>
>>>> Just a few answers to some of your questions in-line, below.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Eike Stepper wrote:
>>>>
>>>> -----8<-----
>>>>
>>>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>>>> early.
>>>>
>>>> As I think St
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427486 is a reply to message #427472] |
Thu, 19 February 2009 11:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Simon,
EMF supports cross resource containment. That means an object x can
have an eContainer as well as an eDirectResource with the implication
that x.eContainer().eResource() != x.eResource(). I'm not sure how
this is possible if the resource is the eContainer; in fact I'm quite
sure it can't work. EPackage.eClassifiers and EPackage.eSubpackages
both support such cross resource containment (any proxy resolving
containment references does), so you could try those as examples. In a
generated editor, you can use "Control..." in the context menu to store
a subpackage or classifier in a separate resource...
Simon Mc Duff wrote:
> Ed Merks schrieb:
>
> Eike,
>
> In all other cases, the eContainer of an object's eContents will be
> that same object. That's because this description of what eContents
> returns is generally expected to be true:
>
> This will be the list of |EObject
>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EObject >|s
>
> determined by the |contents
>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eGet%E2%98%82EStructuralFeature >|
>
> of the |containment features
>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EClass%E2%98%82getEAllContainments >|
>
> of this object's |meta class
>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eClass >|.
>
>
>> So while it looks appealing and reasonable for eContents() to return > >
> getContents(), it's arguably inconsistent with the definition of what
> should > be returned. And while you might be tempted to define a
> containment reference
>> for your resource meta class, that will result in different
>> inconsistencies and won't allow you to support cross resource
>> containment.
>
>> I'm sure we do!
>> I'd have to ask Simon, how exactly ;-)
>
> [SIMON] cdoResource.getContents() eContents is model in CDO. So it
> will return the feature attached to that call.(By the way that feature
> is defined as Containment)
> We didn't touch eContents, so it will take it from
> BasicEObjectImpl.eContents(); It behaves like any other objects.
> eContents will not returns getContent... but will behave lile any
> others objects.
>
> Is it the expected behavior ? (I think so)
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427489 is a reply to message #427486] |
Thu, 19 February 2009 12:16 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Simon,
> EMF supports cross resource containment. That means an object x can
> have an eContainer as well as an eDirectResource with the implication
> that x.eContainer().eResource() != x.eResource().
> this is possible if the resource is the eContainer; in fact I'm quite
> sure it can't work. EPackage.eClassifiers and EPackage.eSubpackages
> both support such cross resource containment (any proxy resolving
> containment references does), so you could try those as examples. In a
> generated editor, you can use "Control..." in the context menu to store
> a subpackage or classifier in a separate resource...
Let's start with an example to be sure I understand what you think could
be a problem.
ROOT -> CDOResource(Root Object, eDirectResource==ROOT, eContainer==NULL)
R1 -> CDOResource (eDirectResource==ROOT,eContainer==null,eResource ==
ROOT)
X3 -> CDOResourceFolder (eDirectResource==ROOT,eContainer==null,eResource
== ROOT)
R2 -> CDOResource(eDirectResource==NULL,eContainer==X3,eResource == ROOT)
X1 -> EObject (eDirectResource==R1,eContainer==null,eResource == R1)
X2 -> EObject (eDirectResource==R2,eContainer==X1, eResource == R2)
This is working well at the moment. X2 is a cross reference. I don't see
any problem there.
Is it what you meant ? You can modify my example if it is not good.
Our testcases for cross-containment are located
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/tests/org.eclipse.emf.cdo.tests/src/org/ecl ipse/emf/cdo/tests/ContainmentTest.java?root=Modeling_Projec t&view=markup
under
testObjectNotSameResourceThanItsContainerCDOANDXMI
testObjectNotSameResourceThanItsContainerCDO
testObjectNotSameResourceThanItsContainer_WithoutCDO
Simon
> Simon Mc Duff wrote:
>> Ed Merks schrieb:
>>
>> Eike,
>>
>> In all other cases, the eContainer of an object's eContents will be
>> that same object. That's because this description of what eContents
>> returns is generally expected to be true:
>>
>> This will be the list of |EObject
>>
>>
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EObject >|s
>>
>> determined by the |contents
>>
>>
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eGet%E2%98%82EStructuralFeature >|
>>
>> of the |containment features
>>
>>
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EClass%E2%98%82getEAllContainments >|
>>
>> of this object's |meta class
>>
>>
< eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eClass >|.
>>
>>
>>> So while it looks appealing and reasonable for eContents() to return > >
>> getContents(), it's arguably inconsistent with the definition of what
>> should > be returned. And while you might be tempted to define a
>> containment reference
>>> for your resource meta class, that will result in different
>>> inconsistencies and won't allow you to support cross resource
>>> containment.
>>
>>> I'm sure we do!
>>> I'd have to ask Simon, how exactly ;-)
>>
>> [SIMON] cdoResource.getContents() eContents is model in CDO. So it
>> will return the feature attached to that call.(By the way that feature
>> is defined as Containment)
>> We didn't touch eContents, so it will take it from
>> BasicEObjectImpl.eContents(); It behaves like any other objects.
>> eContents will not returns getContent... but will behave lile any
>> others objects.
>>
>> Is it the expected behavior ? (I think so)
>>
>>
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427493 is a reply to message #427489] |
Thu, 19 February 2009 15:52 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Simon,
Comments below.
Simon Mc Duff wrote:
> Ed Merks wrote:
>
>> Simon,
>
>> EMF supports cross resource containment. That means an object x can
>> have an eContainer as well as an eDirectResource with the implication
>> that x.eContainer().eResource() != x.eResource(). this is possible
>> if the resource is the eContainer; in fact I'm quite sure it can't
>> work. EPackage.eClassifiers and EPackage.eSubpackages both support
>> such cross resource containment (any proxy resolving containment
>> references does), so you could try those as examples. In a generated
>> editor, you can use "Control..." in the context menu to store a
>> subpackage or classifier in a separate resource...
> Let's start with an example to be sure I understand what you think
> could be a problem.
> ROOT -> CDOResource(Root Object, eDirectResource==ROOT, eContainer==NULL)
> R1 -> CDOResource (eDirectResource==ROOT,eContainer==null,eResource ==
> ROOT)
> X3 -> CDOResourceFolder
> (eDirectResource==ROOT,eContainer==null,eResource == ROOT)
> R2 -> CDOResource(eDirectResource==NULL,eContainer==X3,eResource == ROOT)
> X1 -> EObject (eDirectResource==R1,eContainer==null,eResource == R1)
So X1 is not in R1.eContents()? And X is not containment by any
containment reference of R1?
> X2 -> EObject (eDirectResource==R2,eContainer==X1, eResource == R2)
>
> This is working well at the moment. X2 is a cross reference.
X2 is an object and it presumably in a containment reference of X1.
> I don't see any problem there.
>
> Is it what you meant ? You can modify my example if it is not good.
>
> Our testcases for cross-containment are located
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/tests/org.eclipse.emf.cdo.tests/src/org/ecl ipse/emf/cdo/tests/ContainmentTest.java?root=Modeling_Projec t&view=markup
>
> under testObjectNotSameResourceThanItsContainerCDOANDXMI
> testObjectNotSameResourceThanItsContainerCDO
> testObjectNotSameResourceThanItsContainer_WithoutCDO
If I take any Ecore model and open it in the Sample Ecore editor, I can
click on any EClass and invoke Control... to put that EClass in a
separate resource. Such an EClass will have eResource/eDirectResource
being the new resource it's placed into and will also have the EPackage
it has before as its eContainer and that EPackage will be in the
original resource...
>
> Simon
>
>
>
>> Simon Mc Duff wrote:
>>> Ed Merks schrieb:
>>>
>>> Eike,
>>>
>>> In all other cases, the eContainer of an object's eContents will be
>>> that same object. That's because this description of what eContents
>>> returns is generally expected to be true:
>>>
>>> This will be the list of |EObject
>>>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EObject >|s
>
>>>
>>> determined by the |contents
>>>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eGet%E2%98%82EStructuralFeature >|
>
>>>
>>> of the |containment features
>>>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82EClass%E2%98%82getEAllContainments >|
>
>>>
>>> of this object's |meta class
>>>
> < eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.ec lipse.emf.ecore%7BEObject.java%E2%98%83EObject%7EeContents%E 2%98%82%E2%98%82eClass >|.
>
>>>
>>>
>>>> So while it looks appealing and reasonable for eContents() to
>>>> return > >
>>> getContents(), it's arguably inconsistent with the definition of
>>> what should > be returned. And while you might be tempted to define
>>> a containment reference
>>>> for your resource meta class, that will result in different
>>>> inconsistencies and won't allow you to support cross resource
>>>> containment.
>>>
>>>> I'm sure we do!
>>>> I'd have to ask Simon, how exactly ;-)
>>>
>>> [SIMON] cdoResource.getContents() eContents is model in CDO. So it
>>> will return the feature attached to that call.(By the way that
>>> feature is defined as Containment)
>>> We didn't touch eContents, so it will take it from
>>> BasicEObjectImpl.eContents(); It behaves like any other objects.
>>> eContents will not returns getContent... but will behave lile any
>>> others objects.
>>>
>>> Is it the expected behavior ? (I think so)
>>>
>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427498 is a reply to message #427493] |
Thu, 19 February 2009 17:10 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Good questions... they makes me think!! :-)
>>> EMF supports cross resource containment. That means an object x can
>>> have an eContainer as well as an eDirectResource with the implication
>>> that x.eContainer().eResource() != x.eResource(). this is possible
>>> if the resource is the eContainer; in fact I'm quite sure it can't
>>> work. EPackage.eClassifiers and EPackage.eSubpackages both support
>>> such cross resource containment (any proxy resolving containment
>>> references does), so you could try those as examples. In a generated
>>> editor, you can use "Control..." in the context menu to store a
>>> subpackage or classifier in a separate resource...
>> Let's start with an example to be sure I understand what you think
>> could be a problem.
>> ROOT -> CDOResource(Root Object, eDirectResource==ROOT, eContainer==NULL)
>> R1 -> CDOResource (eDirectResource==ROOT,eContainer==null,eResource ==
>> ROOT)
>> X3 -> CDOResourceFolder
>> (eDirectResource==ROOT,eContainer==null,eResource == ROOT)
>> R2 -> CDOResource(eDirectResource==NULL,eContainer==X3,eResource == ROOT)
>> X1 -> EObject (eDirectResource==R1,eContainer==null,eResource == R1)
> So X1 is not in R1.eContents()?
[SIMON] No. R1.eContents will return X1 because CDOResource.getContents is
defined as a containement feature.
But I agree that X1.eContainer() == null and it is also returns when
eContent().???
Should eContents of a CDOResource be always empty ?
Does this change will affect cross-reference ? If yes... how ?
meanwhile I changed eContents to returns an empty list.
or pure EMF, Resource.eContent doesn't exist !! So either solution should
not affect them.
> And X is not containment by any
> containment reference of R1?
At the moment, no.
>> X2 -> EObject (eDirectResource==R2,eContainer==X1, eResource == R2)
>>
>> This is working well at the moment. X2 is a cross reference.
> X2 is an object and it presumably in a containment reference of X1.
[SIMON] Yes!
>> I don't see any problem there.
>>
>> Is it what you meant ? You can modify my example if it is not good.
>>
>> Our testcases for cross-containment are located
>>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/tests/org.eclipse.emf.cdo.tests/src/org/ecl ipse/emf/cdo/tests/ContainmentTest.java?root=Modeling_Projec t&view=markup
>>
>> under testObjectNotSameResourceThanItsContainerCDOANDXMI
>> testObjectNotSameResourceThanItsContainerCDO
>> testObjectNotSameResourceThanItsContainer_WithoutCDO
> If I take any Ecore model and open it in the Sample Ecore editor, I can
> click on any EClass and invoke Control... to put that EClass in a
> separate resource. Such an EClass will have eResource/eDirectResource
> being the new resource it's placed into and will also have the EPackage
> it has before as its eContainer and that EPackage will be in the
> original resource...
[SIMON]Isn't the same as X2... isn't ? I don't see why it should not work.
Simon
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427502 is a reply to message #427498] |
Thu, 19 February 2009 17:31 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Simon,
Comments below.
Simon Mc Duff wrote:
> Hi Ed,
>
> Good questions... they makes me think!! :-)
>
>>>> EMF supports cross resource containment. That means an object x
>>>> can have an eContainer as well as an eDirectResource with the
>>>> implication that x.eContainer().eResource() != x.eResource().
>>>> this is possible if the resource is the eContainer; in fact I'm
>>>> quite sure it can't work. EPackage.eClassifiers and
>>>> EPackage.eSubpackages both support such cross resource containment
>>>> (any proxy resolving containment references does), so you could try
>>>> those as examples. In a generated editor, you can use "Control..."
>>>> in the context menu to store a subpackage or classifier in a
>>>> separate resource...
>>> Let's start with an example to be sure I understand what you think
>>> could be a problem.
>>> ROOT -> CDOResource(Root Object, eDirectResource==ROOT,
>>> eContainer==NULL)
>>> R1 -> CDOResource (eDirectResource==ROOT,eContainer==null,eResource
>>> == ROOT)
>>> X3 -> CDOResourceFolder
>>> (eDirectResource==ROOT,eContainer==null,eResource == ROOT)
>>> R2 -> CDOResource(eDirectResource==NULL,eContainer==X3,eResource ==
>>> ROOT)
>>> X1 -> EObject (eDirectResource==R1,eContainer==null,eResource == R1)
>> So X1 is not in R1.eContents()?
> [SIMON] No. R1.eContents will return X1 because
> CDOResource.getContents is defined as a containement feature.
That's what I though.
> But I agree that X1.eContainer() == null and it is also returns when
> eContent().???
So that's inconsistent with being in a containment reference.
> Should eContents of a CDOResource be always empty ?
It should only have objects it in that return CDOResource as the
eContainer and return the appropriate eContainmentReference.
> Does this change will affect cross-reference ?
If you strictly implemented containment properly, it would be impossible
to support cross resource containment.
> If yes... how ?
....
> meanwhile I changed eContents to returns an empty list. or pure EMF,
> Resource.eContent doesn't exist !! So either solution should not
> affect them.
>> And X is not containment by any containment reference of R1?
> At the moment, no.
>
>>> X2 -> EObject (eDirectResource==R2,eContainer==X1, eResource == R2)
>>>
>>> This is working well at the moment. X2 is a cross reference.
>> X2 is an object and it presumably in a containment reference of X1.
> [SIMON] Yes!
>>> I don't see any problem there.
>>>
>>> Is it what you meant ? You can modify my example if it is not good.
>>>
>>> Our testcases for cross-containment are located
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/tests/org.eclipse.emf.cdo.tests/src/org/ecl ipse/emf/cdo/tests/ContainmentTest.java?root=Modeling_Projec t&view=markup
>
>>>
>>> under testObjectNotSameResourceThanItsContainerCDOANDXMI
>>> testObjectNotSameResourceThanItsContainerCDO
>>> testObjectNotSameResourceThanItsContainer_WithoutCDO
>> If I take any Ecore model and open it in the Sample Ecore editor, I
>> can click on any EClass and invoke Control... to put that EClass in a
>> separate resource. Such an EClass will have
>> eResource/eDirectResource being the new resource it's placed into and
>> will also have the EPackage it has before as its eContainer and that
>> EPackage will be in the original resource...
> [SIMON]Isn't the same as X2... isn't ? I don't see why it should not
> work.
Imagine X2 being contained by a different resource as well as having X1
as its eContainer. You'd have to may the containment reference has
isProxy true and, if the model is generated, you'd have to turn on the
GenModel option to respect proxy resolving containment.
>
> Simon
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427510 is a reply to message #427506] |
Thu, 19 February 2009 18:51 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030704000108020203080303
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Simon,
Comments below.
Simon Mc Duff wrote:
> Ed Merks wrote:
> Comments below:
>> Imagine X2 being contained by a different resource as well as having
>> X1 as its eContainer. You'd have to may the containment reference
>> has isProxy true and, if the model is generated, you'd have to turn
>> on the GenModel option to respect proxy resolving containment.
>
> [SIMON] I understand that and we have testcases that reproduce that
> successfully.
>
> Here the only fact that I know for now.
> Fact1 : At the moment we are able to have: (X1 and X2 are Eobject not
> CDOResource)
> X1 (container == null, directresource = R1, resource = R1)
> X2 (container == X1, directresource = R2, resource = R2)
That's good.
>
> Right?
> Questions: With the inconsistency of R1.eContents returns objects that
> do not have eContainer == R1... what do we break ? For Pure EMF... we
> do not break anything since they cannot call Resource.eContents. Right ?
Any clients can see an EObject and can use eContents to traverse its
children with the expectation that these objects will have their
eContainer point back because that's how it's been defined to behave.
>
> Can you explains me a context where we break something in Pure EMF and
> why/how ?
Probably this basicEObjectImpl method wouldn't work well:
public String eURIFragmentSegment(EStructuralFeature
eStructuralFeature, EObject eObject)
{
if (eStructuralFeature == null)
{
for (@SuppressWarnings("unchecked")
EContentsEList.FeatureIterator<EObject> crossReferences =
(EContentsEList.FeatureIterator<EObject>)((InternalEList<? >)eCrossReferences()).basicIterator();
crossReferences.hasNext(); )
{
EObject crossReference = crossReferences.next();
if (crossReference == eObject)
{
eStructuralFeature = crossReferences.feature();
}
}
}
Ultimately the point is that there is an invariant that's supposed to
hold and when it doesn't, unpleasant surprises might be the result.
> The context you already explain where "X2 being contained by a
> different resource as well as having X1" is working for a few months
> already...
Yes, because you haven't really implemented Resource.getContents to be
an actual containment feature. You made it behave the way it's supposed
to: orthogonal to EObject containment.
> I suspect that you are trying to tell me something important .. but It
> seems that I'm not fast enough :-(
Hehehe. I'm a stickler about the smallest detail so having eContents
return objects that aren't actually in containment references is simply
inconsistent. Even if that inconsistency causes no apparent problems,
its still an inconsistency...
>
> Simon
>
>
>
--------------030704000108020203080303
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon,<br>
<br>
Comments below.<br>
<br>
Simon Mc Duff wrote:
<blockquote
cite="mid:b99abe01f30218c8cb030ac104dd8ebd$1@www.eclipse.org"
type="cite">Ed Merks wrote:
<br>
Comments below:
<br>
<blockquote type="cite">Imagine X2 being contained by a different
resource as well as having X1 as its eContainer.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427514 is a reply to message #427510] |
Thu, 19 February 2009 19:09 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Simon,
> Comments below.
> Simon Mc Duff wrote:
>> Ed Merks wrote:
>> Comments below:
>>> Imagine X2 being contained by a different resource as well as having
>>> X1 as its eContainer. You'd have to may the containment reference
>>> has isProxy true and, if the model is generated, you'd have to turn
>>> on the GenModel option to respect proxy resolving containment.
>>
>> [SIMON] I understand that and we have testcases that reproduce that
>> successfully.
>>
>> Here the only fact that I know for now.
>> Fact1 : At the moment we are able to have: (X1 and X2 are Eobject not
>> CDOResource)
>> X1 (container == null, directresource = R1, resource = R1)
>> X2 (container == X1, directresource = R2, resource = R2)
> That's good.
>>
>> Right?
>> Questions: With the inconsistency of R1.eContents returns objects that
>> do not have eContainer == R1... what do we break ? For Pure EMF... we
>> do not break anything since they cannot call Resource.eContents. Right ?
> Any clients can see an EObject and can use eContents to traverse its
> children with the expectation that these objects will have their
> eContainer point back because that's how it's been defined to behave.
>>
>> Can you explains me a context where we break something in Pure EMF and
>> why/how ?
> Probably this basicEObjectImpl method wouldn't work well:
> public String eURIFragmentSegment(EStructuralFeature
> eStructuralFeature, EObject eObject)
> {
> if (eStructuralFeature == null)
> {
> for (@SuppressWarnings("unchecked")
> EContentsEList.FeatureIterator<EObject> crossReferences =
>
(EContentsEList.FeatureIterator<EObject>)((InternalEList<? >)eCrossReferences()).basicIterator();
> crossReferences.hasNext(); )
> {
> EObject crossReference = crossReferences.next();
> if (crossReference == eObject)
> {
> eStructuralFeature = crossReferences.feature();
> }
> }
> }
> Ultimately the point is that there is an invariant that's supposed to
> hold and when it doesn't, unpleasant surprises might be the result.
>> The context you already explain where "X2 being contained by a
>> different resource as well as having X1" is working for a few months
>> already...
> Yes, because you haven't really implemented Resource.getContents to be
> an actual containment feature. You made it behave the way it's supposed
> to: orthogonal to EObject containment.
It is a unidirectional containment !! :-)
>> I suspect that you are trying to tell me something important .. but It
>> seems that I'm not fast enough :-(
> Hehehe. I'm a stickler about the smallest detail so having eContents
> return objects that aren't actually in containment references is simply
> inconsistent. Even if that inconsistency causes no apparent problems,
> its still an inconsistency...
if X1 and X2 are not CDOResource it will work... Right? What you are
telling me is if X1 and X2 are CDOResource... it will not work. If it is
what you meant.. I do agree!
One bugzilla that we have will help that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246687
We could also enforce only one of these 2 values could be set for
CDOResource(Only CDOResource)...(eContainer and eDirectResource).
Simon
>>
>> Simon
>>
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427516 is a reply to message #427514] |
Thu, 19 February 2009 19:20 |
|
Guys,
I think the positions are clear now. Our only chance to be 100%
compliant is to remove the EObject contract from CDOResource. This will
not have major impact on the underlying functionality. We'd just have to
separate all the persistence aspects out into a separate interface
(basically it will be like InternalCDOObject) and implement it for
CDOObjects as well as for Resources and RsourceFolders. That's an
internal detail but unfortunately it might cause us a lot of effort. If
there are no volunteers, I fear it might take some time before I come
back to this minor uncompliance issue.
Cheers
/Eike
----
http://thegordian.blogspot.com
Simon Mc Duff schrieb:
> Ed Merks wrote:
>
>> Simon,
>
>> Comments below.
>
>> Simon Mc Duff wrote:
>>> Ed Merks wrote:
>>> Comments below:
>>>> Imagine X2 being contained by a different resource as well as
>>>> having X1 as its eContainer. You'd have to may the containment
>>>> reference has isProxy true and, if the model is generated, you'd
>>>> have to turn on the GenModel option to respect proxy resolving
>>>> containment.
>>>
>>> [SIMON] I understand that and we have testcases that reproduce that
>>> successfully.
>>>
>>> Here the only fact that I know for now.
>>> Fact1 : At the moment we are able to have: (X1 and X2 are Eobject
>>> not CDOResource)
>>> X1 (container == null, directresource = R1, resource = R1)
>>> X2 (container == X1, directresource = R2, resource = R2)
>> That's good.
>>>
>>> Right?
>>> Questions: With the inconsistency of R1.eContents returns objects
>>> that do not have eContainer == R1... what do we break ? For Pure
>>> EMF... we do not break anything since they cannot call
>>> Resource.eContents. Right ?
>> Any clients can see an EObject and can use eContents to traverse its
>> children with the expectation that these objects will have their
>> eContainer point back because that's how it's been defined to behave.
>>>
>>> Can you explains me a context where we break something in Pure EMF
>>> and why/how ?
>> Probably this basicEObjectImpl method wouldn't work well:
>
>> public String eURIFragmentSegment(EStructuralFeature
>> eStructuralFeature, EObject eObject)
>> {
>> if (eStructuralFeature == null)
>> {
>> for (@SuppressWarnings("unchecked")
>> EContentsEList.FeatureIterator<EObject> crossReferences =
>
>>
> (EContentsEList.FeatureIterator<EObject>)((InternalEList<? >)eCrossReferences()).basicIterator();
>
>
>> crossReferences.hasNext(); )
>> {
>> EObject crossReference = crossReferences.next();
>> if (crossReference == eObject)
>> {
>> eStructuralFeature = crossReferences.feature();
>> }
>> }
>> }
>> Ultimately the point is that there is an invariant that's supposed
>> to hold and when it doesn't, unpleasant surprises might be the result.
>
>>> The context you already explain where "X2 being contained by a
>>> different resource as well as having X1" is working for a few months
>>> already...
>> Yes, because you haven't really implemented Resource.getContents to
>> be an actual containment feature. You made it behave the way it's
>> supposed to: orthogonal to EObject containment.
> It is a unidirectional containment !! :-)
>
>>> I suspect that you are trying to tell me something important .. but
>>> It seems that I'm not fast enough :-(
>> Hehehe. I'm a stickler about the smallest detail so having eContents
>> return objects that aren't actually in containment references is
>> simply inconsistent. Even if that inconsistency causes no apparent
>> problems, its still an inconsistency...
> if X1 and X2 are not CDOResource it will work... Right? What you are
> telling me is if X1 and X2 are CDOResource... it will not work. If it
> is what you meant.. I do agree!
>
> One bugzilla that we have will help that:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246687
>
> We could also enforce only one of these 2 values could be set for
> CDOResource(Only CDOResource)...(eContainer and eDirectResource).
>
> Simon
>>>
>>> Simon
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427724 is a reply to message #427437] |
Fri, 27 February 2009 15:13 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Guys,
Are you still integrating CDO / GMF / TED ?
Did you face TED issues ?
From my side, I've implemented, as suggested by Christian, a
CDOTransactionalEditingDomain that implements the API contract of the EMF
Transaction component in CDO terms.
This CDOTransactionalEditingDomain provides a new
TransactionChangeRecorder that overrides notifyChanged(..) and
appendNotification(..) to handle CDOResource correctly.
Changes in the ChangeRecorder class are not necessary any more.
Nevertheless, this bugzilla
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136) has to be fixed.
At the moment, the only one remaining problem is the one described in
this post :
http://www.eclipse.org/newsportal/article.php?id=39440&g roup=eclipse.tools.emf#39440
Stephane.
Christian W. Damus wrote:
> Hi, Eike,
> Let's see whether you can find my replies to your replies in the
> increasing morass of text. :-)
> cW
> Eike Stepper wrote:
>> Hi Christian,
>>
>> Again inline...
>>
>>
>> Christian W. Damus schrieb:
>>> -----8<-----
>>>
>>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>>> early.
>>>
>>> As I think Stéphane also mentioned, it is likely that most of your GMF
>>> problems will boil down to the TED, anyway. :-)
>> That was clear to me ;-)
>> And this way or that way, sooner or later, the TED problem with CDO will
>> pop up again, here.
>>
>> But I still tend to think that, even if we manage (and I'm sure we
>> could) to have two different transaction layers on top of each other,
>> that this is not an ideal solution. It's just that I think that, if you
>> want CDO at the bottom (for the other functionailty, not included in EMF
>> Transations) and GMF at the top of your technology stack, there is
>> really no reason to have a TED in between, other maybe that GMF is
>> currently designed to have it there. I think, if GMF needs
> Yes, that's a key point: the EMF Transaction component (excluding the
> org.eclipse.emf.workspace* plug-ins) originated as a re-design, to
> similar (and a few additional) requirements, of a part of the original
> GMF run-time contribution. The name "Transaction" derives from one of
> the key types in the API which, ironically, ordinary client applications
> never have to deal with.
> Thus, the dependencies in GMF on this layer can be expected to be quite
> extensive. My hope is that it would be possible to implement a
> CDOTransactionalEditingDomain that implements the API contract of the
> EMF Transaction component in CDO terms. This probably wouldn't reuse
> much of the default implementation, but there would probably be
> assumptions within the Transaction API that need to be addressed to make
> it work ...
>> transactionailty and there are multiple Eclipse technologies available
>> to fulfill this demand and there is community demand for more pluggable
>> integration of orthogonal functionality, then clearly GMF should open up
>> this part and give the user the choice. Finally that's the main reason
>> why I (for myself) wanted to go top down, because only then I can see
>> how and where exactly this strong binding to EMF Transaction is in GMF
>> and how we could try to abstract these dependencies away. Whether GMF
>> would consider patches in this area is written on a different page
>> though :P
>>
>>>
>>>
>>>> Nevertheless one question pops into my mind: What is the locking
>>>> granularity of TEDs? EObjects or Resources?
>>>
>>> The ResourceSet. As the TED is a layer on top of EMF, and did not
>>> take the deep integration approach as CDO has done, there was no means
>>> to effectively control concurrent access at the object level or even
>>> the resource level. Certainly, we don't have true transactions in the
>>> usual sense of the word, which is where CDO derives most of the
>>> benefit of its EObject integration.
>> Then, to answer Stephanes question why a TED raises an exception and CDO
>> not, I think this might be the reason:
>>
>> 1) Transaction A modifies Object a in resource X
>> 2) Transaction B modifies Object b in the same resource X (same
>> instance, i.e. same resource set)
>>
>> A TED would complain because it's clear that these two changes would
>> result in a file save conflict. CDO on the other hand would not
> It's not as much about file-save conflicts as it is about concurrent
> access to an EMF run-time system that is inherently not thread-safe. In
> CDO, clients A and B effectively see different states of the same model
> until they commit, after which point they each the changes that the
> other mode. I'm assuming that one of them will not successfully commit
> if it has feature-level conflicts with the other.
> The EMF Transaction component has only one view of the resource set
> contents to offer to all clients, so it implements this coarse-grained
> locking to protect them from getting confused by dirty reads, concurrent
> modification exceptions, etc.
>> recognize any critical situation (if A != B) because CDO transactions
>> collect changes in form of deltas and commits all the deltas to the
>> repository in the end. No conflict, no exception, no problem ;-)
> Yes. A fully transactional environment, which EMF Transaction is not :-P
>>>> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
>>>> behaves like an EContentAdapter (no idea why it isn't).
>>>
>>> EContentAdapters remove themselves from objects that are detached from
>>> the content tree, because they are considered no longer to be of
>>> interest. However, ChangeRecorders do continue to listen to detached
>>> objects because they need to record any changes that may be done while
>>> an object is unattached, so that the ChangeDescription would be able
>>> to undo them (and undo the detachment of the object) coherently.
>> I see, I didn't consider that undo brings additional requirements that
>> play no role in mere transactionality. On the other hand (to return to
> No, it does play a role in transactionality. One of the features of the
> EMF Transaction component is automatic validation of transactions
> (change-sets) with the potential that, if validation fails, the changes
> are rolled back to restore the data to a safe state. The mechanism
> employed in roll-back recording is the (Transaction)ChangeRecorder.
>> my initial motivation) for undo we just need a command stack (or a
>> change recorder) and not a TED. At least not if CDO is underneath anyway.
> It happens that the change recorder also facilitates a convenient means
> to implement undo/redo, using change descriptions that we recorded for
> data integrity purposes, anyway. We make it easy to build the
> command-stack based on the changes that are recorded for roll-back.
>>>
>>>
>>>> While generally EContentAdapters _should_ work with CDO this
>>>> undermines demand-loading of containments, as offered by CDO.
>>>> We should keep in mind that we might have a problem here...
>>>
>>> Oh, yes. I suspect that you will need more control over how and when
>>> objects become available to the change recorder so that it does not
>>> cause the entire repository to be loaded!
>> Yes, in the end the required functionality "I want to see all change"
>> and not "I want to have my whole containment tree adapted (and thereby
>> loaded)". Formerly, in the ancient times of XML file persistence :P ,
>> that might have boiled down to the same thing. But with the availability
>> of containment demand-loading (I think Teneo has similar
>> characteristics, but I'm not sure), this implicit equality should be
>> generally re-considered. Sure, it's a problem that all this code is out
>> there that builds on this assumption...
> Oh, there are all kinds of applications that assume some
> long-since-eliminated limitations of EMF. Many are still trying to
> catch up to the reality of cross-resource-containment, and that was
> released years ago!
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>> 4) Do you already suspect a reason for it?
>>>>>
>>>>>> Christian, you asked "What does CDOResource respond to an
>>>>>> eContents() query?".
>>>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>>>> As a consequence it returns the value of the only modeled
>>>>>> containment feature "contents", i.e. the same as getContents().
>>>
>>> But, Resource doesn't define features: the only model representation
>>> of it is the EResource data type, which being an EDataType, doesn't
>>> have features. So, I would expect that eContents() actually always
>>> returns an empty list.
>> I think this argument is odd ;-)
>> Would you also argue "EObject doesn't define annotations. So, I would
>> expect that EClass.getEAnnotations() actually always returns an empty
>> list."?
> What I meant wasn't that I would expect any resource that is an EObject
> to have no eContents(). Only that I would expect an EObject that has no
> containment references not to return anything from eContents(). For
> some reason, I assumed that CDOResource didn't model the contents-list
> as a containment reference. If it is a containment reference that
> happens to generate a setter named getContents that corresponds to the
> Resource API, then of course it will provide eContents()! :-)
>> And I would say, the absence of a concept in Ecore is usually no ban
>> from other models.
>> Apart from the fact that one concept is modeled (EObject) and one is not
>> (Resource), I still can't see the semantic differences between
>> eContents() and getContents().
> Well, as Ed indicated, it is generally expected that all objects in the
> eContents() list answer the container as their eContainer(). Do the
> roots of a CDOResource answer their eDirectResource() as their
> eContainer()? And what does a CDOResource answer to the eResource()
> query? Itself?
> Resources are outside of the logical model/data that comprises the
> EObject tree. They assign a URI to an extent of objects for location
> and persistence purposes, but otherwise are meaningless. Objects in one
> resource can be moved to another and still mean exactly the same as
> before. A model can be collected under one resource or many; it doesn't
> matter to the semantics.
>> The only effect of making this difference explicit is increased effort
>> to implement the same functionality (notification, containment, ...).
>> Since we have to consider persistence, transactionality and others as
>> well, our effort would be magnitudes higher.
> Maybe the effort would be worthwhile if it avoids confusion of semantics
> that applications expect? I don't know whether it is a practical issue
> for existing applications ... I suspect that most of the interactions
> with resources are based on the a priori knowledge that the object in
> hand is to be treated as a Resource and not as something else.
>> I decided to take a different approach and if you look into the
>> implementation of CDOResourceImpl, where you might expect large amounts
>> of integration code, you'll find only a handful overrides to bring
>> together what belongs together (eContents and contents).
> Well, if you think they belong together ... I'm not convinced that I
> should consider resources as elements of my model. :-)
>> But, back to the initial question, a CDOResource does not return an
>> empty list for eContents(), if getContents() is not empty.
>> I even can't point you to code in CDOResourceImpl where this becomes
>> evident, because there is no such code.
>> getContents() is is a normal containment feature of CDOResource and as a
>> consequence it is considered a valid contributor to eContents() by
>> BasicEObjectImpl ;-)
> Right, because you modeled contents as a containment reference of the
> CDOResource EClass. That's the bit that wasn't clear to me, before, and
> makes all the difference!
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427726 is a reply to message #427724] |
Fri, 27 February 2009 15:22 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Hi Stephane,
We fixed that bugs last week. See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=265114.
Vik continue to see if we have others issues.
Simon
Stéphane Fournier wrote:
> Guys,
> Are you still integrating CDO / GMF / TED ?
> Did you face TED issues ?
> From my side, I've implemented, as suggested by Christian, a
> CDOTransactionalEditingDomain that implements the API contract of the EMF
> Transaction component in CDO terms.
> This CDOTransactionalEditingDomain provides a new
> TransactionChangeRecorder that overrides notifyChanged(..) and
> appendNotification(..) to handle CDOResource correctly.
> Changes in the ChangeRecorder class are not necessary any more.
> Nevertheless, this bugzilla
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136) has to be fixed.
> At the moment, the only one remaining problem is the one described in
> this post :
>
http://www.eclipse.org/newsportal/article.php?id=39440&g roup=eclipse.tools.emf#39440
> Stephane.
> Christian W. Damus wrote:
>> Hi, Eike,
>> Let's see whether you can find my replies to your replies in the
>> increasing morass of text. :-)
>> cW
>> Eike Stepper wrote:
>>> Hi Christian,
>>>
>>> Again inline...
>>>
>>>
>>> Christian W. Damus schrieb:
>>>> -----8<-----
>>>>
>>>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>>>> early.
>>>>
>>>> As I think Stéphane also mentioned, it is likely that most of your GMF
>>>> problems will boil down to the TED, anyway. :-)
>>> That was clear to me ;-)
>>> And this way or that way, sooner or later, the TED problem with CDO will
>>> pop up again, here.
>>>
>>> But I still tend to think that, even if we manage (and I'm sure we
>>> could) to have two different transaction layers on top of each other,
>>> that this is not an ideal solution. It's just that I think that, if you
>>> want CDO at the bottom (for the other functionailty, not included in EMF
>>> Transations) and GMF at the top of your technology stack, there is
>>> really no reason to have a TED in between, other maybe that GMF is
>>> currently designed to have it there. I think, if GMF needs
>> Yes, that's a key point: the EMF Transaction component (excluding the
>> org.eclipse.emf.workspace* plug-ins) originated as a re-design, to
>> similar (and a few additional) requirements, of a part of the original
>> GMF run-time contribution. The name "Transaction" derives from one of
>> the key types in the API which, ironically, ordinary client applications
>> never have to deal with.
>> Thus, the dependencies in GMF on this layer can be expected to be quite
>> extensive. My hope is that it would be possible to implement a
>> CDOTransactionalEditingDomain that implements the API contract of the
>> EMF Transaction component in CDO terms. This probably wouldn't reuse
>> much of the default implementation, but there would probably be
>> assumptions within the Transaction API that need to be addressed to make
>> it work ...
>>> transactionailty and there are multiple Eclipse technologies available
>>> to fulfill this demand and there is community demand for more pluggable
>>> integration of orthogonal functionality, then clearly GMF should open up
>>> this part and give the user the choice. Finally that's the main reason
>>> why I (for myself) wanted to go top down, because only then I can see
>>> how and where exactly this strong binding to EMF Transaction is in GMF
>>> and how we could try to abstract these dependencies away. Whether GMF
>>> would consider patches in this area is written on a different page
>>> though :P
>>>
>>>>
>>>>
>>>>> Nevertheless one question pops into my mind: What is the locking
>>>>> granularity of TEDs? EObjects or Resources?
>>>>
>>>> The ResourceSet. As the TED is a layer on top of EMF, and did not
>>>> take the deep integration approach as CDO has done, there was no means
>>>> to effectively control concurrent access at the object level or even
>>>> the resource level. Certainly, we don't have true transactions in the
>>>> usual sense of the word, which is where CDO derives most of the
>>>> benefit of its EObject integration.
>>> Then, to answer Stephanes question why a TED raises an exception and CDO
>>> not, I think this might be the reason:
>>>
>>> 1) Transaction A modifies Object a in resource X
>>> 2) Transaction B modifies Object b in the same resource X (same
>>> instance, i.e. same resource set)
>>>
>>> A TED would complain because it's clear that these two changes would
>>> result in a file save conflict. CDO on the other hand would not
>> It's not as much about file-save conflicts as it is about concurrent
>> access to an EMF run-time system that is inherently not thread-safe. In
>> CDO, clients A and B effectively see different states of the same model
>> until they commit, after which point they each the changes that the
>> other mode. I'm assuming that one of them will not successfully commit
>> if it has feature-level conflicts with the other.
>> The EMF Transaction component has only one view of the resource set
>> contents to offer to all clients, so it implements this coarse-grained
>> locking to protect them from getting confused by dirty reads, concurrent
>> modification exceptions, etc.
>>> recognize any critical situation (if A != B) because CDO transactions
>>> collect changes in form of deltas and commits all the deltas to the
>>> repository in the end. No conflict, no exception, no problem ;-)
>> Yes. A fully transactional environment, which EMF Transaction is not :-P
>>>>> All this stuff scares me a bit. The reason is that IMO ChangeRecorder
>>>>> behaves like an EContentAdapter (no idea why it isn't).
>>>>
>>>> EContentAdapters remove themselves from objects that are detached from
>>>> the content tree, because they are considered no longer to be of
>>>> interest. However, ChangeRecorders do continue to listen to detached
>>>> objects because they need to record any changes that may be done while
>>>> an object is unattached, so that the ChangeDescription would be able
>>>> to undo them (and undo the detachment of the object) coherently.
>>> I see, I didn't consider that undo brings additional requirements that
>>> play no role in mere transactionality. On the other hand (to return to
>> No, it does play a role in transactionality. One of the features of the
>> EMF Transaction component is automatic validation of transactions
>> (change-sets) with the potential that, if validation fails, the changes
>> are rolled back to restore the data to a safe state. The mechanism
>> employed in roll-back recording is the (Transaction)ChangeRecorder.
>>> my initial motivation) for undo we just need a command stack (or a
>>> change recorder) and not a TED. At least not if CDO is underneath anyway.
>> It happens that the change recorder also facilitates a convenient means
>> to implement undo/redo, using change descriptions that we recorded for
>> data integrity purposes, anyway. We make it easy to build the
>> command-stack based on the changes that are recorded for roll-back.
>>>>
>>>>
>>>>> While generally EContentAdapters _should_ work with CDO this
>>>>> undermines demand-loading of containments, as offered by CDO.
>>>>> We should keep in mind that we might have a problem here...
>>>>
>>>> Oh, yes. I suspect that you will need more control over how and when
>>>> objects become available to the change recorder so that it does not
>>>> cause the entire repository to be loaded!
>>> Yes, in the end the required functionality "I want to see all change"
>>> and not "I want to have my whole containment tree adapted (and thereby
>>> loaded)". Formerly, in the ancient times of XML file persistence :P ,
>>> that might have boiled down to the same thing. But with the availability
>>> of containment demand-loading (I think Teneo has similar
>>> characteristics, but I'm not sure), this implicit equality should be
>>> generally re-considered. Sure, it's a problem that all this code is out
>>> there that builds on this assumption...
>> Oh, there are all kinds of applications that assume some
>> long-since-eliminated limitations of EMF. Many are still trying to
>> catch up to the reality of cross-resource-containment, and that was
>> released years ago!
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> 4) Do you already suspect a reason for it?
>>>>>>
>>>>>>> Christian, you asked "What does CDOResource respond to an
>>>>>>> eContents() query?".
>>>>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>>>>> As a consequence it returns the value of the only modeled
>>>>>>> containment feature "contents", i.e. the same as getContents().
>>>>
>>>> But, Resource doesn't define features: the only model representation
>>>> of it is the EResource data type, which being an EDataType, doesn't
>>>> have features. So, I would expect that eContents() actually always
>>>> returns an empty list.
>>> I think this argument is odd ;-)
>>> Would you also argue "EObject doesn't define annotations. So, I would
>>> expect that EClass.getEAnnotations() actually always returns an empty
>>> list."?
>> What I meant wasn't that I would expect any resource that is an EObject
>> to have no eContents(). Only that I would expect an EObject that has no
>> containment references not to return anything from eContents(). For
>> some reason, I assumed that CDOResource didn't model the contents-list
>> as a containment reference. If it is a containment reference that
>> happens to generate a setter named getContents that corresponds to the
>> Resource API, then of course it will provide eContents()! :-)
>>> And I would say, the absence of a concept in Ecore is usually no ban
>>> from other models.
>>> Apart from the fact that one concept is modeled (EObject) and one is not
>>> (Resource), I still can't see the semantic differences between
>>> eContents() and getContents().
>> Well, as Ed indicated, it is generally expected that all objects in the
>> eContents() list answer the container as their eContainer(). Do the
>> roots of a CDOResource answer their eDirectResource() as their
>> eContainer()? And what does a CDOResource answer to the eResource()
>> query? Itself?
>> Resources are outside of the logical model/data that comprises the
>> EObject tree. They assign a URI to an extent of objects for location
>> and persistence purposes, but otherwise are meaningless. Objects in one
>> resource can be moved to another and still mean exactly the same as
>> before. A model can be collected under one resource or many; it doesn't
>> matter to the semantics.
>>> The only effect of making this difference explicit is increased effort
>>> to implement the same functionality (notification, containment, ...).
>>> Since we have to consider persistence, transactionality and others as
>>> well, our effort would be magnitudes higher.
>> Maybe the effort would be worthwhile if it avoids confusion of semantics
>> that applications expect? I don't know whether it is a practical issue
>> for existing applications ... I suspect that most of the interactions
>> with resources are based on the a priori knowledge that the object in
>> hand is to be treated as a Resource and not as something else.
>>> I decided to take a different approach and if you look into the
>>> implementation of CDOResourceImpl, where you might expect large amounts
>>> of integration code, you'll find only a handful overrides to bring
>>> together what belongs together (eContents and contents).
>> Well, if you think they belong together ... I'm not convinced that I
>> should consider resources as elements of my model. :-)
>>> But, back to the initial question, a CDOResource does not return an
>>> empty list for eContents(), if getContents() is not empty.
>>> I even can't point you to code in CDOResourceImpl where this becomes
>>> evident, because there is no such code.
>>> getContents() is is a normal containment feature of CDOResource and as a
>>> consequence it is considered a valid contributor to eContents() by
>>> BasicEObjectImpl ;-)
>> Right, because you modeled contents as a containment reference of the
>> CDOResource EClass. That's the bit that wasn't clear to me, before, and
>> makes all the difference!
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
|
|
|
| Re: [CDO] [EMF Transaction] CDO with Transactional Editing Domain behavior ? [message #427732 is a reply to message #427724] |
Fri, 27 February 2009 17:20 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Stéphane,
sorry for not giving any news lately, have been über-busy :(
And I started writing the blog-post haven't finished it yet! And there
isn't probably nothing that you don't know already ;)
We have already committed the model1 GMF diagram to start playing
around. For this, you'll need two new projects that would give you some
nice UI support and bootstrapping. Please not these are still
experimental, and it's just intended to play a bit with CDO + GMF.
org.eclipse.emf.cdo.team
org.eclipse.emf.cdo.ui.ide
1. Create a project in project explorer (no java, just normal project)
2. Open Contextual menu -> Team -> Share Project
3. You should see, in addition to installed providers like CVS or SVN, a
CDO provider.
4. Introduce server URI and repository name (Make sure your CDOServer is
running before finishing the wizard!)
You should now see three elements:
a. Registered Packages
b. All available Resources with their current structure in the repository
c. Opened connections (not implemented yet :P)
Now create a new resource and make sure you create some model1 elements
inside (preferred Company, which is the canvas of the GMF diagram).
Now right click on the resource... Voilá! You have there the initialize
diagram action :P Now you can start playing ;)
As Simon pointed out, we've recently committed:
265114: Attaching adapters to resources does not load them?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=265114
I believe it should fix your problem (the CDOID null exception problem).
The initial problem regarding Resource constants is not yet fixed but
Eike is working on it.
Please check out everything from HEAD and let us know if its working for
you. Otherwise, I'll recommend you to create a bugzilla so we can keep
track of it (for your second post problem, I mean :P).
Regarding CDOTransactionalEditingDomain, currently you shouldn't need it
to make GMF work with CDO. As you pointed out in other threads, you
preferred to start "bottom-up" and we did "top-down". However, having
such implementation is interesting because we can "map" better the EMF
Transaction concepts to CDO's, and this would probably introduce, at
least, great performance improvements :) I suggest you open a bugzilla
to keep track of this issue and submit a patch so we can have a look.
I'm not sure how does the build system work, but I guess contributing
such CDOTransactionalEditingDomain would introduce a dependency with EMF
Transaction...
Cheers,
Víctor
Stéphane Fournier escribió:
> Guys,
>
> Are you still integrating CDO / GMF / TED ?
> Did you face TED issues ?
>
> From my side, I've implemented, as suggested by Christian, a
> CDOTransactionalEditingDomain that implements the API contract of the
> EMF Transaction component in CDO terms.
> This CDOTransactionalEditingDomain provides a new
> TransactionChangeRecorder that overrides notifyChanged(..) and
> appendNotification(..) to handle CDOResource correctly.
> Changes in the ChangeRecorder class are not necessary any more.
> Nevertheless, this bugzilla
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136) has to be fixed.
>
> At the moment, the only one remaining problem is the one described in
> this post :
> http://www.eclipse.org/newsportal/article.php?id=39440&g roup=eclipse.tools.emf#39440
>
>
> Stephane.
>
> Christian W. Damus wrote:
>
>> Hi, Eike,
>
>> Let's see whether you can find my replies to your replies in the
>> increasing morass of text. :-)
>
>> cW
>
>> Eike Stepper wrote:
>>> Hi Christian,
>>>
>>> Again inline...
>>>
>>>
>>> Christian W. Damus schrieb:
>>>> -----8<-----
>>>>
>>>>> As I said, I'd prefer not to mix TED problems with GMF problems so
>>>>> early.
>>>>
>>>> As I think Stéphane also mentioned, it is likely that most of your
>>>> GMF problems will boil down to the TED, anyway. :-)
>>> That was clear to me ;-)
>>> And this way or that way, sooner or later, the TED problem with CDO
>>> will pop up again, here.
>>>
>>> But I still tend to think that, even if we manage (and I'm sure we
>>> could) to have two different transaction layers on top of each other,
>>> that this is not an ideal solution. It's just that I think that, if
>>> you want CDO at the bottom (for the other functionailty, not included
>>> in EMF Transations) and GMF at the top of your technology stack,
>>> there is really no reason to have a TED in between, other maybe that
>>> GMF is currently designed to have it there. I think, if GMF needs
>
>> Yes, that's a key point: the EMF Transaction component (excluding the
>> org.eclipse.emf.workspace* plug-ins) originated as a re-design, to
>> similar (and a few additional) requirements, of a part of the original
>> GMF run-time contribution. The name "Transaction" derives from one of
>> the key types in the API which, ironically, ordinary client
>> applications never have to deal with.
>
>> Thus, the dependencies in GMF on this layer can be expected to be
>> quite extensive. My hope is that it would be possible to implement a
>> CDOTransactionalEditingDomain that implements the API contract of the
>> EMF Transaction component in CDO terms. This probably wouldn't reuse
>> much of the default implementation, but there would probably be
>> assumptions within the Transaction API that need to be addressed to
>> make it work ...
>
>
>>> transactionailty and there are multiple Eclipse technologies
>>> available to fulfill this demand and there is community demand for
>>> more pluggable integration of orthogonal functionality, then clearly
>>> GMF should open up this part and give the user the choice. Finally
>>> that's the main reason why I (for myself) wanted to go top down,
>>> because only then I can see how and where exactly this strong binding
>>> to EMF Transaction is in GMF and how we could try to abstract these
>>> dependencies away. Whether GMF would consider patches in this area is
>>> written on a different page though :P
>>>
>>>>
>>>>
>>>>> Nevertheless one question pops into my mind: What is the locking
>>>>> granularity of TEDs? EObjects or Resources?
>>>>
>>>> The ResourceSet. As the TED is a layer on top of EMF, and did not
>>>> take the deep integration approach as CDO has done, there was no
>>>> means to effectively control concurrent access at the object level
>>>> or even the resource level. Certainly, we don't have true
>>>> transactions in the usual sense of the word, which is where CDO
>>>> derives most of the benefit of its EObject integration.
>>> Then, to answer Stephanes question why a TED raises an exception and
>>> CDO not, I think this might be the reason:
>>>
>>> 1) Transaction A modifies Object a in resource X
>>> 2) Transaction B modifies Object b in the same resource X (same
>>> instance, i.e. same resource set)
>>>
>>> A TED would complain because it's clear that these two changes would
>>> result in a file save conflict. CDO on the other hand would not
>
>> It's not as much about file-save conflicts as it is about concurrent
>> access to an EMF run-time system that is inherently not thread-safe.
>> In CDO, clients A and B effectively see different states of the same
>> model until they commit, after which point they each the changes that
>> the other mode. I'm assuming that one of them will not successfully
>> commit if it has feature-level conflicts with the other.
>
>> The EMF Transaction component has only one view of the resource set
>> contents to offer to all clients, so it implements this coarse-grained
>> locking to protect them from getting confused by dirty reads,
>> concurrent modification exceptions, etc.
>
>
>>> recognize any critical situation (if A != B) because CDO transactions
>>> collect changes in form of deltas and commits all the deltas to the
>>> repository in the end. No conflict, no exception, no problem ;-)
>
>> Yes. A fully transactional environment, which EMF Transaction is not :-P
>
>
>>>>> All this stuff scares me a bit. The reason is that IMO
>>>>> ChangeRecorder behaves like an EContentAdapter (no idea why it isn't).
>>>>
>>>> EContentAdapters remove themselves from objects that are detached
>>>> from the content tree, because they are considered no longer to be
>>>> of interest. However, ChangeRecorders do continue to listen to
>>>> detached objects because they need to record any changes that may be
>>>> done while an object is unattached, so that the ChangeDescription
>>>> would be able to undo them (and undo the detachment of the object)
>>>> coherently.
>>> I see, I didn't consider that undo brings additional requirements
>>> that play no role in mere transactionality. On the other hand (to
>>> return to
>
>> No, it does play a role in transactionality. One of the features of
>> the EMF Transaction component is automatic validation of transactions
>> (change-sets) with the potential that, if validation fails, the
>> changes are rolled back to restore the data to a safe state. The
>> mechanism employed in roll-back recording is the
>> (Transaction)ChangeRecorder.
>
>
>>> my initial motivation) for undo we just need a command stack (or a
>>> change recorder) and not a TED. At least not if CDO is underneath
>>> anyway.
>
>> It happens that the change recorder also facilitates a convenient
>> means to implement undo/redo, using change descriptions that we
>> recorded for data integrity purposes, anyway. We make it easy to
>> build the command-stack based on the changes that are recorded for
>> roll-back.
>
>
>>>>
>>>>
>>>>> While generally EContentAdapters _should_ work with CDO this
>>>>> undermines demand-loading of containments, as offered by CDO.
>>>>> We should keep in mind that we might have a problem here...
>>>>
>>>> Oh, yes. I suspect that you will need more control over how and
>>>> when objects become available to the change recorder so that it does
>>>> not cause the entire repository to be loaded!
>>> Yes, in the end the required functionality "I want to see all change"
>>> and not "I want to have my whole containment tree adapted (and
>>> thereby loaded)". Formerly, in the ancient times of XML file
>>> persistence :P , that might have boiled down to the same thing. But
>>> with the availability of containment demand-loading (I think Teneo
>>> has similar characteristics, but I'm not sure), this implicit
>>> equality should be generally re-considered. Sure, it's a problem that
>>> all this code is out there that builds on this assumption...
>
>> Oh, there are all kinds of applications that assume some
>> long-since-eliminated limitations of EMF. Many are still trying to
>> catch up to the reality of cross-resource-containment, and that was
>> released years ago!
>
>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> 4) Do you already suspect a reason for it?
>>>>>>
>>>>>>> Christian, you asked "What does CDOResource respond to an
>>>>>>> eContents() query?".
>>>>>>> CDOResourceImpl does not override BasicEObjectImpl.eContents().
>>>>>>> As a consequence it returns the value of the only modeled
>>>>>>> containment feature "contents", i.e. the same as getContents().
>>>>
>>>> But, Resource doesn't define features: the only model
>>>> representation of it is the EResource data type, which being an
>>>> EDataType, doesn't have features. So, I would expect that
>>>> eContents() actually always returns an empty list.
>>> I think this argument is odd ;-)
>>> Would you also argue "EObject doesn't define annotations. So, I would
>>> expect that EClass.getEAnnotations() actually always returns an empty
>>> list."?
>
>> What I meant wasn't that I would expect any resource that is an
>> EObject to have no eContents(). Only that I would expect an EObject
>> that has no containment references not to return anything from
>> eContents(). For some reason, I assumed that CDOResource didn't model
>> the contents-list as a containment reference. If it is a containment
>> reference that happens to generate a setter named getContents that
>> corresponds to the Resource API, then of course it will provide
>> eContents()! :-)
>
>
>>> And I would say, the absence of a concept in Ecore is usually no ban
>>> from other models.
>>> Apart from the fact that one concept is modeled (EObject) and one is
>>> not (Resource), I still can't see the semantic differences between
>>> eContents() and getContents().
>
>> Well, as Ed indicated, it is generally expected that all objects in
>> the eContents() list answer the container as their eContainer(). Do
>> the roots of a CDOResource answer their eDirectResource() as their
>> eContainer()? And what does a CDOResource answer to the eResource()
>> query? Itself?
>
>> Resources are outside of the logical model/data that comprises the
>> EObject tree. They assign a URI to an extent of objects for location
>> and persistence purposes, but otherwise are meaningless. Objects in
>> one resource can be moved to another and still mean exactly the same
>> as before. A model can be collected under one resource or many; it
>> doesn't matter to the semantics.
>
>
>>> The only effect of making this difference explicit is increased
>>> effort to implement the same functionality (notification,
>>> containment, ...).
>>> Since we have to consider persistence, transactionality and others as
>>> well, our effort would be magnitudes higher.
>
>> Maybe the effort would be worthwhile if it avoids confusion of
>> semantics that applications expect? I don't know whether it is a
>> practical issue for existing applications ... I suspect that most of
>> the interactions with resources are based on the a priori knowledge
>> that the object in hand is to be treated as a Resource and not as
>> something else.
>
>
>>> I decided to take a different approach and if you look into the
>>> implementation of CDOResourceImpl, where you might expect large
>>> amounts of integration code, you'll find only a handful overrides to
>>> bring together what belongs together (eContents and contents).
>
>> Well, if you think they belong together ... I'm not convinced that I
>> should consider resources as elements of my model. :-)
>
>
>>> But, back to the initial question, a CDOResource does not return an
>>> empty list for eContents(), if getContents() is not empty.
>>> I even can't point you to code in CDOResourceImpl where this becomes
>>> evident, because there is no such code.
>>> getContents() is is a normal containment feature of CDOResource and
>>> as a consequence it is considered a valid contributor to eContents()
>>> by BasicEObjectImpl ;-)
>
>> Right, because you modeled contents as a containment reference of the
>> CDOResource EClass. That's the bit that wasn't clear to me, before,
>> and makes all the difference!
>
>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:26:20 GMT 2024
Powered by FUDForum. Page generated in 0.07075 seconds |
] 
Search
Help
Register
Login
Home
