Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » How to copy EObjects from one Resource to another
How to copy EObjects from one Resource to another [message #505711] Mon, 04 January 2010 16:01 Go to next message
Daniel Rippel is currently offline Daniel RippelFriend
Messages: 29
Registered: July 2009
Junior Member
Hi all,

I have a problem concering the storage (files) of eObjects.

SETTING:
I have a Model which is composed of different sub-diagrams. I'm actually
trying to implement a "new model wizard" which allows to create a model
from several predefined models by selecting and combining sub-diagrams.

Actually I
1) Scan a specified directory for exsiting model files (templates) and
load them.
(works fine)
2) The wizard displays all sub-diagrams and the user can select the
desired combination
(works fine)
3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the subdiagrams
and insert them into a newly created model object (created using the
eFactory.INSTANCE of the model).
(Here is where the problems occur)
4) I create a resource and use default wizard code to save the model in
its own file.

PROBLEMS:
The problem I encounter is that the sub-diagrams are only stored as
proxies with the "template file" as eStorage(). Thus all modifications
to the diagrams affect the template (The models relations to the
subdiagrams are set to containment). Moreover, in some cases the
CannonicalEditPolicy fails to update the newly created file on opening
it. The app freezes and crashes with a "Java Heap Space Overflow"
Exception. (The application is set to 1gb Memory and it takes close to a
minute until the error is thrown)

I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
refer to the template file and are only stored as references (href) in
the created model file.
(Modelfile entry:
<SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
)


MY QUESTION:
Is there any easy way to create a real copy of an eObject (in a way that
it will be contained in the new file) or is it possible to somehow
clear the link to the template file?
I already tried to "resolveAll(eObject)" but this makes no difference :)
In my understanding this only surpresses the load on demand behavior
of distributed models.


Sorry for the long text and thank you for your answers and hints in advance!

With Regards,
Daniel
Re: How to copy EObjects from one Resource to another [message #505725 is a reply to message #505711] Mon, 04 January 2010 16:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30631
Registered: July 2009
Senior Member
Daniel,

Comments below.

Daniel Rippel wrote:
> Hi all,
>
> I have a problem concering the storage (files) of eObjects.
>
> SETTING:
> I have a Model which is composed of different sub-diagrams. I'm
> actually trying to implement a "new model wizard" which allows to
> create a model from several predefined models by selecting and
> combining sub-diagrams.
>
> Actually I
> 1) Scan a specified directory for exsiting model files (templates) and
> load them.
> (works fine)
> 2) The wizard displays all sub-diagrams and the user can select the
> desired combination
> (works fine)
> 3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the
> subdiagrams and insert them into a newly created model object (created
> using the eFactory.INSTANCE of the model).
> (Here is where the problems occur)
I suspect if you're calling copy multiple times you should really be
calling copyAll just once...
> 4) I create a resource and use default wizard code to save the model
> in its own file.
>
> PROBLEMS:
> The problem I encounter is that the sub-diagrams are only stored as
> proxies with the "template file" as eStorage().
You're saying there are unresolved proxies when you load the new result,
or when you're loading the thing to be copied?
> Thus all modifications to the diagrams affect the template (The models
> relations to the subdiagrams are set to containment). Moreover, in
> some cases the CannonicalEditPolicy fails to update the newly created
> file on opening it. The app freezes and crashes with a "Java Heap
> Space Overflow" Exception. (The application is set to 1gb Memory and
> it takes close to a minute until the error is thrown)
>
> I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
> refer to the template file and are only stored as references (href) in
> the created model file.
> (Modelfile entry:
> <SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
> href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
> )
Only containment references are copied recursively. Non-containment
references will refer to a copy only if the referenced object has also
been copied at the same time.
>
>
> MY QUESTION:
> Is there any easy way to create a real copy of an eObject (in a way
> that it will be contained in the new file) or is it possible to
> somehow clear the link to the template file?
Do you want this reference to end up null in the copy even though it's
non-null in the original? You'd have to do that manually... Or is the
problem that the template file should also be copied?
> I already tried to "resolveAll(eObject)" but this makes no difference
> :) In my understanding this only surpresses the load on demand
> behavior of distributed models.
Yes, it forces early resolves.
>
>
> Sorry for the long text and thank you for your answers and hints in
> advance!
One question I would ask is why even make copies? Why not just move the
original objects. Moving them out of their containing resource will
have no externally visible effect on that resource unless you save it in
that modified state.
>
> With Regards,
> Daniel
Re: How to copy EObjects from one Resource to another [message #505814 is a reply to message #505725] Tue, 05 January 2010 08:59 Go to previous messageGo to next message
Daniel Rippel is currently offline Daniel RippelFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Ed,

thank you for your suggestions, but I still have the same problem...
I removed all calls of "copy" and instead move the constructed model
directly into the resource. Unfortunately it still remains the same problem:

The template file constains all entries (all containment)
<MODEL xmi:id="_PU9mkeMxEd6pZ6tfMeq-ww">
<SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
xmi:id="_QGcG0OMxEd6pZ6tfMeq-ww" name="Structure Diagram">
<packagedElement xmi:type="uml:Class"
xmi:id="_QksJEOMxEd6pZ6tfMeq-ww" name="Class1"/>
<packagedElement xmi:type="uml:Class"
xmi:id="_SfUpwOMxEd6pZ6tfMeq-ww" name="Class2">
<generalization xmi:type="uml:Generalization"
xmi:id="_WvHrAOMxEd6pZ6tfMeq-ww" general="_QksJEOMxEd6pZ6tfMeq-ww"/>
</packagedElement>
....
</SUBDIAGRAM1>
<SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
xmi:id="_nC8e0OMxEd6pZ6tfMeq-ww" name="Knowledge Diagram">
<packagedElement xmi:type="uml:Class"
xmi:id="_rJp1gOMxEd6pZ6tfMeq-ww" name="Class3">
<ownedAttribute xmi:type="uml:Property"
xmi:id="_sd_yQOMxEd6pZ6tfMeq-ww" name="Property1" aggregation="composite"/>

and so on...

After constructuing the new Diagram and saving the resource I end up with:
<MODEL xmi:id="_AaUgEfnWEd6ukN-HoOMqxQ">
<SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
href="file:/PATH#_QGcG0OMxEd6pZ6tfMeq-ww"/>
<SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
href="file:/PATH#_nC8e0OMxEd6pZ6tfMeq-ww"/>
....


I want the same (complete) information which is stored in the template
to be in the constructed file too. (And not just href links)

For subdiagrams which are constructed programatically this all works
fine (creating the diagram via a command and the factory classes).

I use the following code to load the templates:

URI uri = URI.createFileURI(fPath);
Resource resource = resourceSet.createResource(uri);

resource.load(Collections.EMPTY_MAP);
EList<EObject> contents = resource.getContents();
Model mdl = null;
for (EObject eObject : contents) {
if (eObject instanceof Model) {
mdl = (Model) eObject;
break;
}
}

and then select present subdiagrams by using (getXXXX() != null)
querries to determine if a sub diagram is contained in this template.

After selecting the desired sub diagrams I create an empty model and use
setXXXXX(SUBDIAGRAM) to include the selected ones. This construct is
then passed to the wizards createDiagram(URI diagramURI,
IProgressMonitor progressMonitor) method which is altered to use the
construct instead of creating a new empty model.

As you can see from the XML above all information should be stored in
the file as they all are containment references.

Ed Merks schrieb:
> Daniel,
>
> Comments below.
>
> Daniel Rippel wrote:
>> Hi all,
>>
>> I have a problem concering the storage (files) of eObjects.
>>
>> SETTING:
>> I have a Model which is composed of different sub-diagrams. I'm
>> actually trying to implement a "new model wizard" which allows to
>> create a model from several predefined models by selecting and
>> combining sub-diagrams.
>>
>> Actually I
>> 1) Scan a specified directory for exsiting model files (templates) and
>> load them.
>> (works fine)
>> 2) The wizard displays all sub-diagrams and the user can select the
>> desired combination
>> (works fine)
>> 3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the
>> subdiagrams and insert them into a newly created model object (created
>> using the eFactory.INSTANCE of the model).
>> (Here is where the problems occur)
> I suspect if you're calling copy multiple times you should really be
> calling copyAll just once...
>> 4) I create a resource and use default wizard code to save the model
>> in its own file.
>>
>> PROBLEMS:
>> The problem I encounter is that the sub-diagrams are only stored as
>> proxies with the "template file" as eStorage().
> You're saying there are unresolved proxies when you load the new result,
> or when you're loading the thing to be copied?
>> Thus all modifications to the diagrams affect the template (The models
>> relations to the subdiagrams are set to containment). Moreover, in
>> some cases the CannonicalEditPolicy fails to update the newly created
>> file on opening it. The app freezes and crashes with a "Java Heap
>> Space Overflow" Exception. (The application is set to 1gb Memory and
>> it takes close to a minute until the error is thrown)
>>
>> I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
>> refer to the template file and are only stored as references (href) in
>> the created model file.
>> (Modelfile entry:
>> <SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
>> href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
>> )
> Only containment references are copied recursively. Non-containment
> references will refer to a copy only if the referenced object has also
> been copied at the same time.
>>
>>
>> MY QUESTION:
>> Is there any easy way to create a real copy of an eObject (in a way
>> that it will be contained in the new file) or is it possible to
>> somehow clear the link to the template file?
> Do you want this reference to end up null in the copy even though it's
> non-null in the original? You'd have to do that manually... Or is the
> problem that the template file should also be copied?
>> I already tried to "resolveAll(eObject)" but this makes no difference
>> :) In my understanding this only surpresses the load on demand
>> behavior of distributed models.
> Yes, it forces early resolves.
>>
>>
>> Sorry for the long text and thank you for your answers and hints in
>> advance!
> One question I would ask is why even make copies? Why not just move the
> original objects. Moving them out of their containing resource will
> have no externally visible effect on that resource unless you save it in
> that modified state.
>>
>> With Regards,
>> Daniel
Re: How to copy EObjects from one Resource to another [message #505861 is a reply to message #505814] Tue, 05 January 2010 11:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30631
Registered: July 2009
Senior Member
Daniel,

Comments below.

Daniel Rippel wrote:
> Hi Ed,
>
> thank you for your suggestions, but I still have the same problem...
> I removed all calls of "copy" and instead move the constructed model
> directly into the resource. Unfortunately it still remains the same
> problem:
So it's not a copy problem.
>
> The template file constains all entries (all containment)
> <MODEL xmi:id="_PU9mkeMxEd6pZ6tfMeq-ww">
> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
> xmi:id="_QGcG0OMxEd6pZ6tfMeq-ww" name="Structure Diagram">
> <packagedElement xmi:type="uml:Class"
> xmi:id="_QksJEOMxEd6pZ6tfMeq-ww" name="Class1"/>
> <packagedElement xmi:type="uml:Class"
> xmi:id="_SfUpwOMxEd6pZ6tfMeq-ww" name="Class2">
> <generalization xmi:type="uml:Generalization"
> xmi:id="_WvHrAOMxEd6pZ6tfMeq-ww" general="_QksJEOMxEd6pZ6tfMeq-ww"/>
> </packagedElement>
> ...
> </SUBDIAGRAM1>
> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
> xmi:id="_nC8e0OMxEd6pZ6tfMeq-ww" name="Knowledge Diagram">
> <packagedElement xmi:type="uml:Class"
> xmi:id="_rJp1gOMxEd6pZ6tfMeq-ww" name="Class3">
> <ownedAttribute xmi:type="uml:Property"
> xmi:id="_sd_yQOMxEd6pZ6tfMeq-ww" name="Property1"
> aggregation="composite"/>
>
> and so on...
>
> After constructuing the new Diagram and saving the resource I end up
> with:
> <MODEL xmi:id="_AaUgEfnWEd6ukN-HoOMqxQ">
> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
> href="file:/PATH#_QGcG0OMxEd6pZ6tfMeq-ww"/>
> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
> href="file:/PATH#_nC8e0OMxEd6pZ6tfMeq-ww"/>
> ...
Is the containment reference a proxy resolving one? In that case cross
resource containment is supported so it will be neccessary to explicitly
remove the subdiagrams from their resource, i.e., using
resource.getContents().remove or clear.
>
>
> I want the same (complete) information which is stored in the template
> to be in the constructed file too. (And not just href links)
>
> For subdiagrams which are constructed programatically this all works
> fine (creating the diagram via a command and the factory classes).
>
> I use the following code to load the templates:
>
> URI uri = URI.createFileURI(fPath);
> Resource resource = resourceSet.createResource(uri);
>
> resource.load(Collections.EMPTY_MAP);
> EList<EObject> contents = resource.getContents();
> Model mdl = null;
> for (EObject eObject : contents) {
> if (eObject instanceof Model) {
> mdl = (Model) eObject;
> break;
> }
> }
>
> and then select present subdiagrams by using (getXXXX() != null)
> querries to determine if a sub diagram is contained in this template.
>
> After selecting the desired sub diagrams I create an empty model and
> use setXXXXX(SUBDIAGRAM) to include the selected ones. This construct
> is then passed to the wizards createDiagram(URI diagramURI,
> IProgressMonitor progressMonitor) method which is altered to use the
> construct instead of creating a new empty model.
>
> As you can see from the XML above all information should be stored in
> the file as they all are containment references.
It sounds likely that the containment reference is proxy resolving and
that you'll have to explicitly remove the referenced objects from their
containing resource.
>
> Ed Merks schrieb:
>> Daniel,
>>
>> Comments below.
>>
>> Daniel Rippel wrote:
>>> Hi all,
>>>
>>> I have a problem concering the storage (files) of eObjects.
>>>
>>> SETTING:
>>> I have a Model which is composed of different sub-diagrams. I'm
>>> actually trying to implement a "new model wizard" which allows to
>>> create a model from several predefined models by selecting and
>>> combining sub-diagrams.
>>>
>>> Actually I
>>> 1) Scan a specified directory for exsiting model files (templates)
>>> and load them.
>>> (works fine)
>>> 2) The wizard displays all sub-diagrams and the user can select the
>>> desired combination
>>> (works fine)
>>> 3) I use ECoreUtil.copy(SUBDIAGRAM) to create copies of the
>>> subdiagrams and insert them into a newly created model object
>>> (created using the eFactory.INSTANCE of the model).
>>> (Here is where the problems occur)
>> I suspect if you're calling copy multiple times you should really be
>> calling copyAll just once...
>>> 4) I create a resource and use default wizard code to save the model
>>> in its own file.
>>>
>>> PROBLEMS:
>>> The problem I encounter is that the sub-diagrams are only stored as
>>> proxies with the "template file" as eStorage().
>> You're saying there are unresolved proxies when you load the new
>> result, or when you're loading the thing to be copied?
>>> Thus all modifications to the diagrams affect the template (The
>>> models relations to the subdiagrams are set to containment).
>>> Moreover, in some cases the CannonicalEditPolicy fails to update the
>>> newly created file on opening it. The app freezes and crashes with a
>>> "Java Heap Space Overflow" Exception. (The application is set to 1gb
>>> Memory and it takes close to a minute until the error is thrown)
>>>
>>> I use ECoreUtil to copy the eObjects (sub-diagrams), but they still
>>> refer to the template file and are only stored as references (href)
>>> in the created model file.
>>> (Modelfile entry:
>>> <SUBDIAGRAM xmi:type="DIAGRAM_TYPE"
>>> href="file:/PATH_TO_THE_TEMPLATEFILE#_QGcG0OMxEd6pZ6tfMeq-ww "/>
>>> )
>> Only containment references are copied recursively. Non-containment
>> references will refer to a copy only if the referenced object has
>> also been copied at the same time.
>>>
>>>
>>> MY QUESTION:
>>> Is there any easy way to create a real copy of an eObject (in a way
>>> that it will be contained in the new file) or is it possible to
>>> somehow clear the link to the template file?
>> Do you want this reference to end up null in the copy even though
>> it's non-null in the original? You'd have to do that manually... Or
>> is the problem that the template file should also be copied?
>>> I already tried to "resolveAll(eObject)" but this makes no
>>> difference :) In my understanding this only surpresses the load on
>>> demand behavior of distributed models.
>> Yes, it forces early resolves.
>>>
>>>
>>> Sorry for the long text and thank you for your answers and hints in
>>> advance!
>> One question I would ask is why even make copies? Why not just move
>> the original objects. Moving them out of their containing resource
>> will have no externally visible effect on that resource unless you
>> save it in that modified state.
>>>
>>> With Regards,
>>> Daniel
Re: How to copy EObjects from one Resource to another [message #506100 is a reply to message #505861] Wed, 06 January 2010 02:40 Go to previous message
Daniel Rippel is currently offline Daniel RippelFriend
Messages: 29
Registered: July 2009
Junior Member
Thank you Ed! Removing the eObjects from the source resource works
perfectly. I Added the resource.getContents().clear; resource.unload();
and everything works fine! No heap space problems and the file looks
like it should :)

Thank you very much!
Daniel


Ed Merks schrieb:
> Daniel,
>
> Comments below.
>
> Daniel Rippel wrote:
>> Hi Ed,
>>
>> thank you for your suggestions, but I still have the same problem...
>> I removed all calls of "copy" and instead move the constructed model
>> directly into the resource. Unfortunately it still remains the same
>> problem:
> So it's not a copy problem.
>>
>> The template file constains all entries (all containment)
>> <MODEL xmi:id="_PU9mkeMxEd6pZ6tfMeq-ww">
>> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
>> xmi:id="_QGcG0OMxEd6pZ6tfMeq-ww" name="Structure Diagram">
>> <packagedElement xmi:type="uml:Class"
>> xmi:id="_QksJEOMxEd6pZ6tfMeq-ww" name="Class1"/>
>> <packagedElement xmi:type="uml:Class"
>> xmi:id="_SfUpwOMxEd6pZ6tfMeq-ww" name="Class2">
>> <generalization xmi:type="uml:Generalization"
>> xmi:id="_WvHrAOMxEd6pZ6tfMeq-ww" general="_QksJEOMxEd6pZ6tfMeq-ww"/>
>> </packagedElement>
>> ...
>> </SUBDIAGRAM1>
>> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
>> xmi:id="_nC8e0OMxEd6pZ6tfMeq-ww" name="Knowledge Diagram">
>> <packagedElement xmi:type="uml:Class"
>> xmi:id="_rJp1gOMxEd6pZ6tfMeq-ww" name="Class3">
>> <ownedAttribute xmi:type="uml:Property"
>> xmi:id="_sd_yQOMxEd6pZ6tfMeq-ww" name="Property1"
>> aggregation="composite"/>
>>
>> and so on...
>>
>> After constructuing the new Diagram and saving the resource I end up
>> with:
>> <MODEL xmi:id="_AaUgEfnWEd6ukN-HoOMqxQ">
>> <SUBDIAGRAM1 xmi:type="SUBDIAGRAM_TYPE"
>> href="file:/PATH#_QGcG0OMxEd6pZ6tfMeq-ww"/>
>> <SUBDIAGRAM2 xmi:type="SUBDIAGRAM_TYPE2"
>> href="file:/PATH#_nC8e0OMxEd6pZ6tfMeq-ww"/>
>> ...
> Is the containment reference a proxy resolving one? In that case cross
> resource containment is supported so it will be neccessary to explicitly
> remove the subdiagrams from their resource, i.e., using
> resource.getContents().remove or clear.
>>
>>
>> I want the same (complete) information which is stored in the template
>> to be in the constructed file too. (And not just href links)
>>
>> For subdiagrams which are constructed programatically this all works
>> fine (creating the diagram via a command and the factory classes).
>>
>> I use the following code to load the templates:
>>
>> URI uri = URI.createFileURI(fPath);
>> Resource resource = resourceSet.createResource(uri);
>>
>> resource.load(Collections.EMPTY_MAP);
>> EList<EObject> contents = resource.getContents();
>> Model mdl = null;
>> for (EObject eObject : contents) {
>> if (eObject instanceof Model) {
>> mdl = (Model) eObject;
>> break;
>> }
>> }
>>
>> and then select present subdiagrams by using (getXXXX() != null)
>> querries to determine if a sub diagram is contained in this template.
>>
>> After selecting the desired sub diagrams I create an empty model and
>> use setXXXXX(SUBDIAGRAM) to include the selected ones. This construct
>> is then passed to the wizards createDiagram(URI diagramURI,
>> IProgressMonitor progressMonitor) method which is altered to use the
>> construct instead of creating a new empty model.
>>
>> As you can see from the XML above all information should be stored in
>> the file as they all are containment references.
> It sounds likely that the containment reference is proxy resolving and
> that you'll have to explicitly remove the referenced objects from their
> containing resource.
Previous Topic:Genmodel produces Object references rather than EObject - why?
Next Topic:Newlines in generated code
Goto Forum:
  


Current Time: Thu Nov 14 23:52:51 GMT 2019

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

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

Back to the top