| (no subject) [message #687443] |
Sun, 12 June 2011 23:27  |
 Josh
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hello,
I am currently trying to migrate an EMF model into CDO for the first time. Our current EMF model structure is made up of many resources (approaches one resource per EMF object) using containment proxies. The model is structured with a single root element (in a root resource) and the root's children in separate resources (and their children, and so forth). My goal is after the import, for the model to be structured in a single CDOResource (the root) at the CDO server, and have no dependencies on the former XMI files.
[Source Model Example]
-root (XMIResource #1)
--node_1 (XMIResource #2)
---node_1.1 (XMIResource #3)
----leaf_1.1.1 (XMIResource #4)
--node_2 (XMIResource #5)
---leaf_2.2 (XMIResource #6)
[Target Model Desired]
-root (CDOResource #1)
--node_1 (CDOResource #1)
---node_1.1 (CDOResource #1)
----leaf_1.1.1 (CDOResource #1)
--node_2 (CDOResource #1)
---leaf_2.2 (CDOResource #1)
My current effort seems to import the root resource just fine, but the children are still pointing to their XMI resources. I determined this to be the case using the CDO Session viewer. I renamed the directory on the file system, and after opening a view, I would get a FileNotFoundException stating that it could not find the directory original directory when trying to load a child.
Can any one provide some guidance on how best to achieve this kind of import? I don't mind having to do this programmatically, as this import routine will eventually be placed inside an import wizard for our users to migrate legacy models.
Also, am I off-base with thinking that this is the best way to represent the model once inside CDO (single resource), or are their benefits that I am not aware of for leaving each child in a separate CDOResource similar to how it was structured in its original EMF model?
Thanks ahead of time for any help you can provide!
|
|
|
| Re: Importing EMF model into CDO repository [message #687444 is a reply to message #687443] |
Mon, 13 June 2011 04:24  |
|
Hi Josh,
Comments below...
Am 13.06.2011 01:27, schrieb Josh:
> Hello,
> I am currently trying to migrate an EMF model into CDO for the first time. Our current EMF model structure is made up of many resources (approaches one resource per EMF object) using containment proxies. The model is structured with a single root element (in a root resource) and the root's children in separate resources (and their children, and so forth). My goal is after the import, for the model to be structured in a single CDOResource (the root) at the CDO server, and have no dependencies on the former XMI files.
>
> [Source Model Example]
> -root (XMIResource #1)
> --node_1 (XMIResource #2)
> ---node_1.1 (XMIResource #3)
> ----leaf_1.1.1 (XMIResource #4)
> --node_2 (XMIResource #5)
> ---leaf_2.2 (XMIResource #6)
>
> [Target Model Desired]
> -root (CDOResource #1)
> --node_1 (CDOResource #1)
> ---node_1.1 (CDOResource #1)
> ----leaf_1.1.1 (CDOResource #1)
> --node_2 (CDOResource #1)
> ---leaf_2.2 (CDOResource #1)
>
> My current effort seems to import the root resource just fine, but the children are still pointing to their XMI resources.
It seems that you've written kind of a test case for CDO's capability of dealing with "external references" :P
CDO also supports containment proxies, but they're not widely used because their main reasoning (file based scalability) is not valid in CDO.
Importing a *huge* model into a CDO repository is not a trivial task because the change set that results from the import modifications is kept completely in memory until it gets committed. Committing the import in smaller chunks is necessary but often tricky because of possible forward references. Unfortunately noone wanted to fund the development of a generic mechanism for huge imports that could be shipped with CDO.
This newsgroup contains several threads regarding this topic (search for "import"). If that does not help, please show us your import (pseudo) code so that we can comment and possibly improve it.
> I determined this to be the case using the CDO Session viewer. I renamed the directory on the file system, and after opening a view, I would get a FileNotFoundException stating that it could not find the directory original directory when trying to load a child.
>
> Can any one provide some guidance on how best to achieve this kind of import? I don't mind having to do this programmatically, as this import routine will eventually be placed inside an import wizard for our users to migrate legacy models.
>
> Also, am I off-base with thinking that this is the best way to represent the model once inside CDO (single resource), or are their benefits that I am not aware of for leaving each child in a separate CDOResource similar to how it was structured in its original EMF model?
You're right in that you don't need to use multiple resource in CDO to control the loading and unloading granule. All objects in CDO (including resource and folder objects) are loaded and unloaded by themselves as necessary. I tend to see resources as normal objects in the overall object graph, but with a well-known name (a named entry point into the graph). Note that in CDO there are also other entry menchanisms like CDOView.getObject(CDOID) or CDOView.createQuery(...).getResult().
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.01788 seconds
] 
Search
Help
Register
Login
Home
