Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Import a fragmented model ?
[CDO] Import a fragmented model ? [message #631216] Wed, 06 October 2010 15:23 Go to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi,

I have end-users that share a model with a SCM (e.g SVN) tool.
To be able to work as a team, they fragment the model to limit concurrent accesses on the same model elements to ease merge operations.

We are thinking moving on CDO, and I was thinking importing their model as is.
I've given it a try from the CDO session but when committing the resource that contains an element that is held by the first resource, I get an DanglingReferenceException.

Is there, out of the box (CDO 3), another way to import many resources ?

Stephane.
Re: [CDO] Import a fragmented model ? [message #631232 is a reply to message #631216] Wed, 06 October 2010 15:53 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
Registered: July 2009
Location: Germany
Senior Member
Hi Stephane,

comments below.

On 06.10.2010 17:23, Stéphane Fournier wrote:
> Hi,
>
> I have end-users that share a model with a SCM (e.g SVN) tool.
> To be able to work as a team, they fragment the model to limit
> concurrent accesses on the same model elements to ease merge operations.
>
> We are thinking moving on CDO, and I was thinking importing their model
> as is.
> I've given it a try from the CDO session but when committing the
> resource that contains an element that is held by the first resource, I
> get an DanglingReferenceException.
>
> Is there, out of the box (CDO 3), another way to import many resources ?

I'm not sure if this is what you mean. If I understand you correctly,
you have a model which is distributed among several resources.

CDO can store references to external resources (e.g., XMI files). To do
this, however, the resources must be contained in the same resourceSet.
If this is the case you should be able to commit your resources one by
one and thus migrate your model step by step.


Cheers,
Stefan
Re: [CDO] Import a fragmented model ? [message #631233 is a reply to message #631216] Wed, 06 October 2010 15:55 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Hi Stephane,

There's no way of importing (committing) models with dangling references.

But you can import multiple resources in one commit operation with some code like this:

Collection<Resource> resourcesToImport = null;
CDOTransaction transaction = null;

EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all roots
for (Resource resourceToImport : resourcesToImport)
{

Collection<EObject> copiedObjects = copier.copyAll(resourceToImport.getContents());
String targetPath = resourceToImport.getURI().path();
CDOResource cdoResource = transaction.createResource(targetPath);
cdoResource.getContents().addAll(copiedObjects);
}

copier.copyReferences();
transaction.commit();

I haven't tried it. Can you report how it works for you?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 06.10.2010 17:23, schrieb Stéphane Fournier:
> Hi,
>
> I have end-users that share a model with a SCM (e.g SVN) tool.
> To be able to work as a team, they fragment the model to limit concurrent accesses on the same model elements to ease merge operations.
>
> We are thinking moving on CDO, and I was thinking importing their model as is.
> I've given it a try from the CDO session but when committing the resource that contains an element that is held by the first resource, I get an DanglingReferenceException.
>
> Is there, out of the box (CDO 3), another way to import many resources ?
>
> Stephane.
>


Re: [CDO] Import a fragmented model ? [message #631663 is a reply to message #631233] Fri, 08 October 2010 12:12 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi Eike,
Sorry for the delay, I was very busy, I've only test your code right now.

It imports all resources with their content but once imported the link
between resources are lost and objects are duplicated.

Le me give you a schema of my input model.

Resource A contains :
- root object A
- contains object B (hosted in resource B), it's just a HREF to
another resource...
- root object A1
- contains object C (hosted in resource C) it's just a HREF to another
resource...

Resource B contains :
- root object B

Resource C contains :
- root object C

When imported in CDO I got 3 resources, great !
But :
CDO Resource A contains:
-root object A
- contains a local copy of B (OID 10).
- contains a local copy of C.
CDO Resource B contains :
- root object B (OID 50)

CDO Resource C contains :
- root object C


If I modify the local copy of B, object B contained in CDO resource B is
not modified. For sure their OID are different ones.



Any idea to fix that ?

Thanks for your help,
Stephane.


On 06/10/2010 17:55, Eike Stepper wrote:
> Hi Stephane,
>
> There's no way of importing (committing) models with dangling references.
>
> But you can import multiple resources in one commit operation with some
> code like this:
>
> Collection<Resource> resourcesToImport = null;
> CDOTransaction transaction = null;
>
> EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all roots
> for (Resource resourceToImport : resourcesToImport)
> {
>
> Collection<EObject> copiedObjects =
> copier.copyAll(resourceToImport.getContents());
> String targetPath = resourceToImport.getURI().path();
> CDOResource cdoResource = transaction.createResource(targetPath);
> cdoResource.getContents().addAll(copiedObjects);
> }
>
> copier.copyReferences();
> transaction.commit();
>
> I haven't tried it. Can you report how it works for you?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 06.10.2010 17:23, schrieb Stéphane Fournier:
>> Hi,
>>
>> I have end-users that share a model with a SCM (e.g SVN) tool.
>> To be able to work as a team, they fragment the model to limit
>> concurrent accesses on the same model elements to ease merge operations.
>>
>> We are thinking moving on CDO, and I was thinking importing their
>> model as is.
>> I've given it a try from the CDO session but when committing the
>> resource that contains an element that is held by the first resource,
>> I get an DanglingReferenceException.
>>
>> Is there, out of the box (CDO 3), another way to import many resources ?
>>
>> Stephane.
>>
Re: [CDO] Import a fragmented model ? [message #631673 is a reply to message #631663] Fri, 08 October 2010 12:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Hi Stephane,

Can you provide me with a test case for our test framework that demonstrates that? You can use a bugzilla if you want...

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 08.10.2010 14:12, schrieb Stephane Fournier:
> Hi Eike,
> Sorry for the delay, I was very busy, I've only test your code right now.
>
> It imports all resources with their content but once imported the link between resources are lost and objects are duplicated.
>
> Le me give you a schema of my input model.
>
> Resource A contains :
> - root object A
> - contains object B (hosted in resource B), it's just a HREF to another resource...
> - root object A1
> - contains object C (hosted in resource C) it's just a HREF to another resource...
>
> Resource B contains :
> - root object B
>
> Resource C contains :
> - root object C
>
> When imported in CDO I got 3 resources, great !
> But :
> CDO Resource A contains:
> -root object A
> - contains a local copy of B (OID 10).
> - contains a local copy of C.
> CDO Resource B contains :
> - root object B (OID 50)
>
> CDO Resource C contains :
> - root object C
>
>
> If I modify the local copy of B, object B contained in CDO resource B is not modified. For sure their OID are different ones.
>
>
>
> Any idea to fix that ?
>
> Thanks for your help,
> Stephane.
>
>
> On 06/10/2010 17:55, Eike Stepper wrote:
>> Hi Stephane,
>>
>> There's no way of importing (committing) models with dangling references.
>>
>> But you can import multiple resources in one commit operation with some
>> code like this:
>>
>> Collection<Resource> resourcesToImport = null;
>> CDOTransaction transaction = null;
>>
>> EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all roots
>> for (Resource resourceToImport : resourcesToImport)
>> {
>>
>> Collection<EObject> copiedObjects =
>> copier.copyAll(resourceToImport.getContents());
>> String targetPath = resourceToImport.getURI().path();
>> CDOResource cdoResource = transaction.createResource(targetPath);
>> cdoResource.getContents().addAll(copiedObjects);
>> }
>>
>> copier.copyReferences();
>> transaction.commit();
>>
>> I haven't tried it. Can you report how it works for you?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 06.10.2010 17:23, schrieb Stéphane Fournier:
>>> Hi,
>>>
>>> I have end-users that share a model with a SCM (e.g SVN) tool.
>>> To be able to work as a team, they fragment the model to limit
>>> concurrent accesses on the same model elements to ease merge operations.
>>>
>>> We are thinking moving on CDO, and I was thinking importing their
>>> model as is.
>>> I've given it a try from the CDO session but when committing the
>>> resource that contains an element that is held by the first resource,
>>> I get an DanglingReferenceException.
>>>
>>> Is there, out of the box (CDO 3), another way to import many resources ?
>>>
>>> Stephane.
>>>
>


Re: [CDO] Import a fragmented model ? [message #631679 is a reply to message #631673] Fri, 08 October 2010 12:56 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Ok,
For sure I can give you a test case. We need to have a common model to
be able to load the model instance from your side.
Which model would you like me to use ? Is there such a model in CDO
tests, i can reuse to demonstrate that ?

Stephane.

On 08/10/2010 14:38, Eike Stepper wrote:
> Hi Stephane,
>
> Can you provide me with a test case for our test framework that
> demonstrates that? You can use a bugzilla if you want...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 08.10.2010 14:12, schrieb Stephane Fournier:
>> Hi Eike,
>> Sorry for the delay, I was very busy, I've only test your code right now.
>>
>> It imports all resources with their content but once imported the link
>> between resources are lost and objects are duplicated.
>>
>> Le me give you a schema of my input model.
>>
>> Resource A contains :
>> - root object A
>> - contains object B (hosted in resource B), it's just a HREF to
>> another resource...
>> - root object A1
>> - contains object C (hosted in resource C) it's just a HREF to another
>> resource...
>>
>> Resource B contains :
>> - root object B
>>
>> Resource C contains :
>> - root object C
>>
>> When imported in CDO I got 3 resources, great !
>> But :
>> CDO Resource A contains:
>> -root object A
>> - contains a local copy of B (OID 10).
>> - contains a local copy of C.
>> CDO Resource B contains :
>> - root object B (OID 50)
>>
>> CDO Resource C contains :
>> - root object C
>>
>>
>> If I modify the local copy of B, object B contained in CDO resource B
>> is not modified. For sure their OID are different ones.
>>
>>
>>
>> Any idea to fix that ?
>>
>> Thanks for your help,
>> Stephane.
>>
>>
>> On 06/10/2010 17:55, Eike Stepper wrote:
>>> Hi Stephane,
>>>
>>> There's no way of importing (committing) models with dangling
>>> references.
>>>
>>> But you can import multiple resources in one commit operation with some
>>> code like this:
>>>
>>> Collection<Resource> resourcesToImport = null;
>>> CDOTransaction transaction = null;
>>>
>>> EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all
>>> roots
>>> for (Resource resourceToImport : resourcesToImport)
>>> {
>>>
>>> Collection<EObject> copiedObjects =
>>> copier.copyAll(resourceToImport.getContents());
>>> String targetPath = resourceToImport.getURI().path();
>>> CDOResource cdoResource = transaction.createResource(targetPath);
>>> cdoResource.getContents().addAll(copiedObjects);
>>> }
>>>
>>> copier.copyReferences();
>>> transaction.commit();
>>>
>>> I haven't tried it. Can you report how it works for you?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Am 06.10.2010 17:23, schrieb Stéphane Fournier:
>>>> Hi,
>>>>
>>>> I have end-users that share a model with a SCM (e.g SVN) tool.
>>>> To be able to work as a team, they fragment the model to limit
>>>> concurrent accesses on the same model elements to ease merge
>>>> operations.
>>>>
>>>> We are thinking moving on CDO, and I was thinking importing their
>>>> model as is.
>>>> I've given it a try from the CDO session but when committing the
>>>> resource that contains an element that is held by the first resource,
>>>> I get an DanglingReferenceException.
>>>>
>>>> Is there, out of the box (CDO 3), another way to import many
>>>> resources ?
>>>>
>>>> Stephane.
>>>>
>>
Re: [CDO] Import a fragmented model ? [message #631684 is a reply to message #631679] Fri, 08 October 2010 13:22 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Am 08.10.2010 14:56, schrieb Stephane Fournier:
> Ok,
> For sure I can give you a test case. We need to have a common model to be able to load the model instance from your side.
> Which model would you like me to use ? Is there such a model in CDO tests, i can reuse to demonstrate that ?
Sure, there are severals. You start with something like this:

public class MyTest extends AbstractCDOTest
{
public void testXyz() throws Exception
{
CDOSession session = openSession();
CDOTransaction transaction = session.openTransaction();
CDOResource resource = transaction.createResource("/test1");

Supplier supplier = getModel1Factory().createSupplier();
supplier.setName("Stepper");

resource.getContents().add(supplier);
transaction.commit();
}
}

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> Stephane.
>
> On 08/10/2010 14:38, Eike Stepper wrote:
>> Hi Stephane,
>>
>> Can you provide me with a test case for our test framework that
>> demonstrates that? You can use a bugzilla if you want...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 08.10.2010 14:12, schrieb Stephane Fournier:
>>> Hi Eike,
>>> Sorry for the delay, I was very busy, I've only test your code right now.
>>>
>>> It imports all resources with their content but once imported the link
>>> between resources are lost and objects are duplicated.
>>>
>>> Le me give you a schema of my input model.
>>>
>>> Resource A contains :
>>> - root object A
>>> - contains object B (hosted in resource B), it's just a HREF to
>>> another resource...
>>> - root object A1
>>> - contains object C (hosted in resource C) it's just a HREF to another
>>> resource...
>>>
>>> Resource B contains :
>>> - root object B
>>>
>>> Resource C contains :
>>> - root object C
>>>
>>> When imported in CDO I got 3 resources, great !
>>> But :
>>> CDO Resource A contains:
>>> -root object A
>>> - contains a local copy of B (OID 10).
>>> - contains a local copy of C.
>>> CDO Resource B contains :
>>> - root object B (OID 50)
>>>
>>> CDO Resource C contains :
>>> - root object C
>>>
>>>
>>> If I modify the local copy of B, object B contained in CDO resource B
>>> is not modified. For sure their OID are different ones.
>>>
>>>
>>>
>>> Any idea to fix that ?
>>>
>>> Thanks for your help,
>>> Stephane.
>>>
>>>
>>> On 06/10/2010 17:55, Eike Stepper wrote:
>>>> Hi Stephane,
>>>>
>>>> There's no way of importing (committing) models with dangling
>>>> references.
>>>>
>>>> But you can import multiple resources in one commit operation with some
>>>> code like this:
>>>>
>>>> Collection<Resource> resourcesToImport = null;
>>>> CDOTransaction transaction = null;
>>>>
>>>> EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all
>>>> roots
>>>> for (Resource resourceToImport : resourcesToImport)
>>>> {
>>>>
>>>> Collection<EObject> copiedObjects =
>>>> copier.copyAll(resourceToImport.getContents());
>>>> String targetPath = resourceToImport.getURI().path();
>>>> CDOResource cdoResource = transaction.createResource(targetPath);
>>>> cdoResource.getContents().addAll(copiedObjects);
>>>> }
>>>>
>>>> copier.copyReferences();
>>>> transaction.commit();
>>>>
>>>> I haven't tried it. Can you report how it works for you?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://www.esc-net.de
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>> Am 06.10.2010 17:23, schrieb Stéphane Fournier:
>>>>> Hi,
>>>>>
>>>>> I have end-users that share a model with a SCM (e.g SVN) tool.
>>>>> To be able to work as a team, they fragment the model to limit
>>>>> concurrent accesses on the same model elements to ease merge
>>>>> operations.
>>>>>
>>>>> We are thinking moving on CDO, and I was thinking importing their
>>>>> model as is.
>>>>> I've given it a try from the CDO session but when committing the
>>>>> resource that contains an element that is held by the first resource,
>>>>> I get an DanglingReferenceException.
>>>>>
>>>>> Is there, out of the box (CDO 3), another way to import many
>>>>> resources ?
>>>>>
>>>>> Stephane.
>>>>>
>>>
>


Re: [CDO] Import a fragmented model ? [message #631741 is a reply to message #631684] Fri, 08 October 2010 15:17 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080809080606080705020709
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Please find attached the test case.
At the moment, I don't file a bugzilla as I cannot run the test case. My
env does not allow me to run it.

Could you please let me, if you get the issue ?

Stephane.

On 08/10/2010 15:22, Eike Stepper wrote:
> Am 08.10.2010 14:56, schrieb Stephane Fournier:
>> Ok,
>> For sure I can give you a test case. We need to have a common model
>> to be able to load the model instance from your side.
>> Which model would you like me to use ? Is there such a model in CDO
>> tests, i can reuse to demonstrate that ?
> Sure, there are severals. You start with something like this:
>
> public class MyTest extends AbstractCDOTest
> {
> public void testXyz() throws Exception
> {
> CDOSession session = openSession();
> CDOTransaction transaction = session.openTransaction();
> CDOResource resource = transaction.createResource("/test1");
>
> Supplier supplier = getModel1Factory().createSupplier();
> supplier.setName("Stepper");
>
> resource.getContents().add(supplier);
> transaction.commit();
> }
> }
>
> Cheers
> /Eike


--------------080809080606080705020709
Content-Type: text/plain;
name="MyTest.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="MyTest.java"

LyoqDQogKiANCiAqLw0KcGFja2FnZSBvcmcuY2RvLnRlc3Q7DQoNCmltcG9y dCBqYXZhLnV0
aWwuQ29sbGVjdGlvbjsNCg0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8u ZXJlc291cmNl
LkNET1Jlc291cmNlOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8uc2Vz c2lvbi5DRE9T
ZXNzaW9uOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8udGVzdHMuQWJz dHJhY3RDRE9U
ZXN0Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8udGVzdHMubW9kZWwx LkNvbXBhbnk7
DQppbXBvcnQgb3JnLmVjbGlwc2UuZW1mLmNkby50ZXN0cy5tb2RlbDEuQ3Vz dG9tZXI7DQpp
bXBvcnQgb3JnLmVjbGlwc2UuZW1mLmNkby50ZXN0cy5tb2RlbDEuTW9kZWwx RmFjdG9yeTsN
CmltcG9ydCBvcmcuZWNsaXBzZS5lbWYuY2RvLnRyYW5zYWN0aW9uLkNET1Ry YW5zYWN0aW9u
Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jb21tb24udXRpbC5VUkk7DQpp bXBvcnQgb3Jn
LmVjbGlwc2UuZW1mLmVjb3JlLkVPYmplY3Q7DQppbXBvcnQgb3JnLmVjbGlw c2UuZW1mLmVj
b3JlLnJlc291cmNlLlJlc291cmNlOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVt Zi5lY29yZS5y
ZXNvdXJjZS5SZXNvdXJjZVNldDsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYu ZWNvcmUucmVz
b3VyY2UuaW1wbC5SZXNvdXJjZVNldEltcGw7DQppbXBvcnQgb3JnLmVjbGlw c2UuZW1mLmVj
b3JlLnV0aWwuRWNvcmVVdGlsOw0KDQovKioNCiAqIEBhdXRob3IgU3RlcGhh bmUgRm91cm5p
ZXINCiAqIA0KICovDQpwdWJsaWMgY2xhc3MgTXlUZXN0IGV4dGVuZHMgQWJz dHJhY3RDRE9U
ZXN0IHsNCglwdWJsaWMgdm9pZCB0ZXN0SW1wb3J0Q29udHJvbGxlZE1vZGVs KCkgdGhyb3dz
IEV4Y2VwdGlvbiB7DQoJCVJlc291cmNlU2V0IHJlc291cmNlU2V0ID0gbmV3 IFJlc291cmNl
U2V0SW1wbCgpOw0KCQkvLyBDcmVhdGUgYSBzdGFuZGFyZCBFTUYgcmVzb3Vy Y2UNCgkJUmVz
b3VyY2UgbWFpblJlc291cmNlID0gcmVzb3VyY2VTZXQuY3JlYXRlUmVzb3Vy Y2UoVVJJDQoJ
CQkJLmNyZWF0ZVVSSSgibWFpbi54bWwiKSk7DQoNCgkJTW9kZWwxRmFjdG9y eSBtb2RlbDFG
YWN0b3J5ID0gZ2V0TW9kZWwxRmFjdG9yeSgpOw0KCQkvLyBDcmVhdGUgYSBD b21wYW55Lg0K
CQlDb21wYW55IGNvbXBhbnkgPSBtb2RlbDFGYWN0b3J5LmNyZWF0ZUNvbXBh bnkoKTsNCgkJ
Y29tcGFueS5zZXROYW1lKCJUSEFMRVMiKTsNCgkJLy8gQWRkIGl0IGluIG1h aW4gcmVzb3Vy
Y2UuDQoJCW1haW5SZXNvdXJjZS5nZXRDb250ZW50cygpLmFkZChjb21wYW55 KTsNCgkJLy8g
Q3JlYXRlIGEgY3VzdG9tZXIuDQoJCUN1c3RvbWVyIGN1c3RvbWVyID0gbW9k ZWwxRmFjdG9y
eS5jcmVhdGVDdXN0b21lcigpOw0KCQljdXN0b21lci5zZXROYW1lKCJTdGVw aGFuZSIpOw0K
CQljdXN0b21lci5zZXRDaXR5KCJQYXJpcyIpOw0KCQkvLyBBZGQgdGhpcyBj dXN0b21lciBh
cyBjb21wYW55J3MgY3VzdG9tZXJzDQoJCWNvbXBhbnkuZ2V0Q3VzdG9tZXJz KCkuYWRkKGN1
c3RvbWVyKTsNCg0KCQkvLyBMZXQgY3JlYXRlIGEgc2Vjb25kIHJlc291cmNl DQoJCVJlc291
cmNlIHNlY29uZFJlc291cmNlID0gcmVzb3VyY2VTZXQuY3JlYXRlUmVzb3Vy Y2UoVVJJDQoJ
CQkJLmNyZWF0ZVVSSSgic2Vjb25kLnhtbCIpKTsNCgkJLy8gQXQgdGhlIG1v bWVudCBjdXN0
b21lciBpcyBzdG9yZWQgaW4gbWFpblJlc291cmNlLg0KCQkvLyBSZW1vdmUg aXQgZnJvbSBt
YWluUmVzb3VyY2UgdG8gcHV0IGl0IGluIHNlY29uZFJlc291cmNlIChmYWtl DQoJCS8vIENv
bnRyb2wuLi4gRU1GIGFjdGlvbikuDQoJCW1haW5SZXNvdXJjZS5nZXRDb250 ZW50cygpLnJl
bW92ZShjdXN0b21lcik7DQoJCS8vIEFkZCBpdCB0byBzZWNvbmRSZXNvdXJj ZS4NCgkJc2Vj
b25kUmVzb3VyY2UuZ2V0Q29udGVudHMoKS5hZGQoY3VzdG9tZXIpOw0KDQoJ CS8vIEF0IHRo
aXMgcG9pbnQsIHdlIGhhdmUgMiByZXNvdXJjZXMgOiBtYWluUmVzb3VyY2Ug dGhhdCBob2xk
cyBjb21wYW55DQoJCS8vIHdoaWNoIGNvbnRhaW5zIGEgY3VzdG9tZXIgc3Rv cmVkIGluIHNl
Y29uZFJlc291cmNlOw0KCQkvLyByaWdodCA/DQoNCgkJQ0RPU2Vzc2lvbiBz ZXNzaW9uID0g
b3BlblNlc3Npb24oKTsNCgkJQ0RPVHJhbnNhY3Rpb24gdHJhbnNhY3Rpb24g PSBzZXNzaW9u
Lm9wZW5UcmFuc2FjdGlvbigpOw0KDQoJCUVjb3JlVXRpbC5Db3BpZXIgY29w aWVyID0gbmV3
IEVjb3JlVXRpbC5Db3BpZXIoKTsgLy8gQSBDb3BpZXIgZm9yIGFsbA0KCQkJ CQkJCQkJCQkJ
CQkJLy8gcm9vdHMNCgkJZm9yIChSZXNvdXJjZSByZXNvdXJjZVRvSW1wb3J0 IDogcmVzb3Vy
Y2VTZXQuZ2V0UmVzb3VyY2VzKCkpIHsNCg0KCQkJQ29sbGVjdGlvbjxFT2Jq ZWN0PiBjb3Bp
ZWRPYmplY3RzID0gY29waWVyLmNvcHlBbGwocmVzb3VyY2VUb0ltcG9ydA0K CQkJCQkuZ2V0
Q29udGVudHMoKSk7DQoJCQlTdHJpbmcgdGFyZ2V0UGF0aCA9IHJlc291cmNl VG9JbXBvcnQu
Z2V0VVJJKCkucGF0aCgpOw0KCQkJQ0RPUmVzb3VyY2UgY2RvUmVzb3VyY2Ug PSB0cmFuc2Fj
dGlvbi5jcmVhdGVSZXNvdXJjZSh0YXJnZXRQYXRoKTsNCgkJCWNkb1Jlc291 cmNlLmdldENv
bnRlbnRzKCkuYWRkQWxsKGNvcGllZE9iamVjdHMpOw0KCQl9DQoNCgkJY29w aWVyLmNvcHlS
ZWZlcmVuY2VzKCk7DQoJCXRyYW5zYWN0aW9uLmNvbW1pdCgpOw0KCQkvLyBO b3cgYm90aCBy
ZXNvdXJjZXMgYXJlIGltcG9ydGVkIGluIHRoZSByZXBvc2l0b3J5Lg0KCQkv LyBOZXZlcnRo
ZWxlc3MsIGN1c3RvbWVyIG9iamVjdCBpcyBkdXBsaWNhdGVkLiBUaGUgb25l IGhlbGQgYnkg
dGhlDQoJCS8vIGNvbXBhbnkgaXMgbm90IHRoZSBvbmUgY29udGFpbmVkIGRp cmVjdGx5IGJ5
IHRoZSBzZWNvbmRSZXNvdXJjZS4NCgkJLy8gT0lEcyBhcmUgZGlmZmVyZW50 IG9uZXMuIE1v
ZGlmeWluZyB0aGUgZmlyc3QgaGFzIG5vIGVmZmVjdCBvbiB0aGUgb25lDQoJ CS8vIGRpcmVj
dGx5IGNvbnRhaW5lZCBieSB0aGUgc2Vjb25kUmVzb3VyY2UuDQoJfQ0KfQ0K
--------------080809080606080705020709--
Re: [CDO] Import a fragmented model ? [message #631851 is a reply to message #631741] Sat, 09 October 2010 05:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Hi Stephane,

Your test case is based on two incorrect assumptions:

1) mainResource.getContents().remove(customer);

This is a no-op because mainResource contains a single Company object, no Customer. Unfortunately the silly Java Collection framework tends to silently ignbore this.

2) secondResource.getContents().add(customer);

This instead removes the customer implicitely from ((Company)mainResource.getContents().get(0)).getCustomers() because the customers reference in Company is a containment reference and the customer can not be contained by two containers at the same time.

It's best to proof such assertions in the code, then it becomes evident immediately. I've updated your test case as follows:

public class MyTest extends AbstractCDOTest
{
public void testImportControlledModel() throws Exception
{
Customer customer = getModel1Factory().createCustomer();
customer.setName("Stephane");
customer.setCity("Paris");

Company company = getModel1Factory().createCompany();
company.setName("THALES");
company.getCustomers().add(customer);

ResourceSet resourceSet = new ResourceSetImpl();
Map<String, Object> map = resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap();
map.put("xml", new XMLResourceFactoryImpl());

Resource mainResource = resourceSet.createResource(URI.createURI("main.xml"));
Resource secondResource = resourceSet.createResource(URI.createURI("second.xml"));

mainResource.getContents().add(company);

// At the moment customer is stored in mainResource.
// Remove it from mainResource to put it in secondResource (fake
// Control... EMF action).
boolean removed = mainResource.getContents().remove(customer);
assertEquals(true, removed); // FAILS!!!

// Add it to secondResource.
secondResource.getContents().add(customer);

// At this point, we have 2 resources : mainResource that holds company
// which contains a customer stored in secondResource;
// right ?
assertEquals(customer, secondResource.getContents().get(0));
assertEquals(customer, ((Company)mainResource.getContents().get(0)).getCustomers(). get(0)); // FAILS!!!

CDOSession session = openSession();
CDOTransaction transaction = session.openTransaction();

EcoreUtil.Copier copier = new EcoreUtil.Copier(); // A Copier for all
// roots
for (Resource resourceToImport : resourceSet.getResources())
{

Collection<EObject> copiedObjects = copier.copyAll(resourceToImport.getContents());
String targetPath = resourceToImport.getURI().path();
CDOResource cdoResource = transaction.createResource(targetPath);
cdoResource.getContents().addAll(copiedObjects);
}

copier.copyReferences();
transaction.commit();
// Now both resources are imported in the repository.
// Nevertheless, customer object is duplicated. The one held by the
// company is not the one contained directly by the secondResource.
// OIDs are different ones. Modifying the first has no effect on the one
// directly contained by the secondResource.
}
}

If I comment out the new assertions the test case passes for me, so I'm still unsure what your problem is about ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 08.10.2010 17:17, schrieb Stephane Fournier:
> Please find attached the test case.
> At the moment, I don't file a bugzilla as I cannot run the test case. My env does not allow me to run it.
>
> Could you please let me, if you get the issue ?
>
> Stephane.
>
> On 08/10/2010 15:22, Eike Stepper wrote:
>> Am 08.10.2010 14:56, schrieb Stephane Fournier:
>>> Ok,
>>> For sure I can give you a test case. We need to have a common model
>>> to be able to load the model instance from your side.
>>> Which model would you like me to use ? Is there such a model in CDO
>>> tests, i can reuse to demonstrate that ?
>> Sure, there are severals. You start with something like this:
>>
>> public class MyTest extends AbstractCDOTest
>> {
>> public void testXyz() throws Exception
>> {
>> CDOSession session = openSession();
>> CDOTransaction transaction = session.openTransaction();
>> CDOResource resource = transaction.createResource("/test1");
>>
>> Supplier supplier = getModel1Factory().createSupplier();
>> supplier.setName("Stepper");
>>
>> resource.getContents().add(supplier);
>> transaction.commit();
>> }
>> }
>>
>> Cheers
>> /Eike
>


Re: [CDO] Import a fragmented model ? [message #631865 is a reply to message #631851] Sat, 09 October 2010 11:27 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi Eike,

I tried to fake the ControlAction provided by EMF.Edit, it seems I failed.

As I told you, I can't run the test case so it is difficult to check if my problem is demonstrated.
On Monday, I will debug the behavior of the ControlAction that seems to run a RemoveCommand + AddCommand, that I tried to fake.

I will create real XML files for the Company, Customer, model from a generic EMF editor to get the 2 files. That's simpler. I will adapt the test case to load these files instead of creating objects.

The relationship between Company and Customer is a containment one, right. Hence a customer can be only contained by one container, right. Nevertheless, through EMF control mechanism the Customer objects can be stored in a different resource from the one that contains the Company. The customer's container is always the Company but its eResource is not null and refers to the second resource.

We will meet us in a week or two Wink, so I would have the opportunity to show you the issue.

Stephane.

[Updated on: Sat, 09 October 2010 11:28]

Report message to a moderator

Re: [CDO] Import a fragmented model ? [message #632004 is a reply to message #631865] Mon, 11 October 2010 07:53 Go to previous message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080403050505060200050204
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Eike,
I re-generate the java code for model1 meta-model to enable containment
proxies genmodel property.
I've created a dummy model with generic EMF-based editor (see attachment
files).
There is a main model file that contains a company that contains 2
customers. Each one is stored in its own resource second.xml (and
third.xml).
I've updated the test case to load the main.xml rather than creating
objects...

Could you test that and let me know if you reproduce the issue ?
My issue is : when the model is imported in a CDO repo (I got 3 CDO
resources), both customers are duplicated.
Hence dealing with the ones contained by the company do not modify the
object contained by each customer's resource.

Stephane.


On 09/10/2010 13:27, Stéphane Fournier wrote:
> Hi Eike,
>
> I tried to fake the ControlAction provided by EMF.Edit, it seems I failed.
>
> As I told you, I can't run the test case so it is difficult to check if
> my problem is demonstrated.
> On Monday, I will debug the behavior of the ControlAction that seems to
> run a RemoveCommand + AddCommand, that I tried to fake.
>
> I will create real XML files for the Company, Customer, model from a
> generic EMF editor to get the 2 files. That's simpler. I will adapt the
> test case to load these file instead of creating objects.
>
> The relationship between Company and Customer is a containment one,
> right. Hence a customer can be only contained by a container, right.
> Nevertheless, through EMF control mechanism the Customer objects can be
> stored in a different resource from the one that contains the Company.
> The customer's container is always the Company but its eResource is not
> null and refers to the second resource.
>
> We will meet us in a week or two ;), so I would have the opportunity to
> show you the issue.
>
> Stephane.


--------------080403050505060200050204
Content-Type: text/xml;
name="third.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="third.xml"

<?xml version="1.0" encoding="ASCII"?>
<model1:Customer xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:model1="http://www.eclipse.org/emf/CDO/tests/model1/1.0.0" name="Eike" city="Berlin"/>

--------------080403050505060200050204
Content-Type: text/xml;
name="main.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="main.xml"

<?xml version="1.0" encoding="UTF-8"?>
<model1:Company xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:model1="http://www.eclipse.org/emf/CDO/tests/model1/1.0.0" name="Acme">
<customers href="second.xml#/"/>
<customers href="third.xml#/"/>
</model1:Company>

--------------080403050505060200050204
Content-Type: text/xml;
name="second.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="second.xml"

<?xml version="1.0" encoding="ASCII"?>
<model1:Customer xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:model1="http://www.eclipse.org/emf/CDO/tests/model1/1.0.0" name="Stephane" city="Paris"/>

--------------080403050505060200050204
Content-Type: text/plain;
name="MyTest.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="MyTest.java"

LyoqDQogKiANCiAqLw0KcGFja2FnZSBvcmcuY2RvLnRlc3Q7DQoNCmltcG9y dCBqYXZhLnV0
aWwuQ29sbGVjdGlvbjsNCg0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8u ZXJlc291cmNl
LkNET1Jlc291cmNlOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8uc2Vz c2lvbi5DRE9T
ZXNzaW9uOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8udGVzdHMuQWJz dHJhY3RDRE9U
ZXN0Ow0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jZG8udHJhbnNhY3Rpb24u Q0RPVHJhbnNh
Y3Rpb247DQppbXBvcnQgb3JnLmVjbGlwc2UuZW1mLmNvbW1vbi51aS5kaWFs b2dzLlJlc291
cmNlRGlhbG9nOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS5FT2Jq ZWN0Ow0KaW1w
b3J0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS5yZXNvdXJjZS5SZXNvdXJjZTsN CmltcG9ydCBv
cmcuZWNsaXBzZS5lbWYuZWNvcmUucmVzb3VyY2UuUmVzb3VyY2VTZXQ7DQpp bXBvcnQgb3Jn
LmVjbGlwc2UuZW1mLmVjb3JlLnJlc291cmNlLmltcGwuUmVzb3VyY2VTZXRJ bXBsOw0KaW1w
b3J0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS51dGlsLkVjb3JlVXRpbDsNCmlt cG9ydCBvcmcu
ZWNsaXBzZS5qZmFjZS53aW5kb3cuV2luZG93Ow0KaW1wb3J0IG9yZy5lY2xp cHNlLnN3dC5T
V1Q7DQppbXBvcnQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuU2hlbGw7DQoN Ci8qKg0KICog
QGF1dGhvciBTdGVwaGFuZSBGb3Vybmllcg0KICovDQpwdWJsaWMgY2xhc3Mg TXlUZXN0IGV4
dGVuZHMgQWJzdHJhY3RDRE9UZXN0IHsNCglwdWJsaWMgdm9pZCB0ZXN0SW1w b3J0Q29udHJv
bGxlZE1vZGVsKCkgdGhyb3dzIEV4Y2VwdGlvbiB7DQoJCVJlc291cmNlU2V0 IHJlc291cmNl
U2V0ID0gbmV3IFJlc291cmNlU2V0SW1wbCgpOw0KDQoJCVJlc291cmNlRGlh bG9nIGRpYWxv
ZyA9IG5ldyBSZXNvdXJjZURpYWxvZyhuZXcgU2hlbGwoKSwNCgkJCQkiU2Vs ZWN0IGEgbW9k
ZWwiLCBTV1QuT1BFTik7DQoJCWlmIChXaW5kb3cuT0sgIT0gZGlhbG9nLm9w ZW4oKSkgew0K
CQkJcmV0dXJuOw0KCQl9DQoJCS8vIENyZWF0ZSBhIHN0YW5kYXJkIEVNRiBy ZXNvdXJjZQ0K
CQlSZXNvdXJjZSBtYWluUmVzb3VyY2UgPSByZXNvdXJjZVNldC5nZXRSZXNv dXJjZSgNCgkJ
CQlkaWFsb2cuZ2V0VVJJcygpLmdldCgwKSwgdHJ1ZSk7DQoJCS8vIE1ha2Ug c3VyZSBhbGwg
ZGVwZW5kZW50IHJlc291cmNlcyBhcmUgbG9hZGVkLg0KCQlFY29yZVV0aWwu cmVzb2x2ZUFs
bChtYWluUmVzb3VyY2UpOw0KCQlFY29yZVV0aWwucmVzb2x2ZUFsbChyZXNv dXJjZVNldCk7
DQoJCQ0KCQlDRE9TZXNzaW9uIHNlc3Npb24gPSBvcGVuU2Vzc2lvbigpOw0K CQlDRE9UcmFu
c2FjdGlvbiB0cmFuc2FjdGlvbiA9IHNlc3Npb24ub3BlblRyYW5zYWN0aW9u KCk7DQoNCgkJ
RWNvcmVVdGlsLkNvcGllciBjb3BpZXIgPSBuZXcgRWNvcmVVdGlsLkNvcGll cigpOyAvLyBB
IENvcGllciBmb3IgYWxsDQoJCQkJCQkJCQkJCQkJCQkvLyByb290cw0KCQlm b3IgKFJlc291
cmNlIHJlc291cmNlVG9JbXBvcnQgOiByZXNvdXJjZVNldC5nZXRSZXNvdXJj ZXMoKSkgew0K
CQkJLy8gT25seSBpbXBvcnQgb3VyIHhtbCBmaWxlcy4NCgkJCWlmIChyZXNv dXJjZVRvSW1w
b3J0LmdldFVSSSgpLnBhdGgoKS5lbmRzV2l0aCgieG1sIikpIHsNCgkJCQlD b2xsZWN0aW9u
PEVPYmplY3Q+IGNvcGllZE9iamVjdHMgPSBjb3BpZXINCgkJCQkJCS5jb3B5 QWxsKHJlc291
cmNlVG9JbXBvcnQuZ2V0Q29udGVudHMoKSk7DQoJCQkJU3RyaW5nIHRhcmdl dFBhdGggPSBy
ZXNvdXJjZVRvSW1wb3J0LmdldFVSSSgpLnBhdGgoKTsNCgkJCQlDRE9SZXNv dXJjZSBjZG9S
ZXNvdXJjZSA9IHRyYW5zYWN0aW9uDQoJCQkJCQkuY3JlYXRlUmVzb3VyY2Uo dGFyZ2V0UGF0
aCk7DQoJCQkJY2RvUmVzb3VyY2UuZ2V0Q29udGVudHMoKS5hZGRBbGwoY29w aWVkT2JqZWN0
cyk7DQoJCQl9DQoJCX0NCg0KCQljb3BpZXIuY29weVJlZmVyZW5jZXMoKTsN CgkJdHJhbnNh
Y3Rpb24uY29tbWl0KCk7DQoJCS8vIE5vdyBib3RoIHJlc291cmNlcyBhcmUg aW1wb3J0ZWQg
aW4gdGhlIHJlcG9zaXRvcnkuDQoJCS8vIE5ldmVydGhlbGVzcywgY3VzdG9t ZXIgb2JqZWN0
IGlzIGR1cGxpY2F0ZWQuIFRoZSBvbmUgaGVsZCBieSB0aGUNCgkJLy8gY29t cGFueSBpcyBu
b3QgdGhlIG9uZSBjb250YWluZWQgZGlyZWN0bHkgYnkgdGhlIHNlY29uZFJl c291cmNlLg0K
CQkvLyBPSURzIGFyZSBkaWZmZXJlbnQgb25lcy4gTW9kaWZ5aW5nIHRoZSBm aXJzdCBoYXMg
bm8gZWZmZWN0IG9uIHRoZSBvbmUNCgkJLy8gZGlyZWN0bHkgY29udGFpbmVk IGJ5IHRoZSBz
ZWNvbmRSZXNvdXJjZS4NCgl9DQp9DQo=
--------------080403050505060200050204--
Previous Topic:[CDO] Dispatch of CDO Notifications
Next Topic:UML class model
Goto Forum:
  


Current Time: Wed Oct 23 13:42:02 GMT 2019

Powered by FUDForum. Page generated in 0.03590 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top