Home » Modeling » EMF » Storing an ecore model into several files
Storing an ecore model into several files [message #535657] |
Tue, 25 May 2010 07:36 |
Eclipse User |
|
|
|
Originally posted by: templth.yahoo.fr
Hello,
I try to store an ecore model within several files in order to prevent
from having one big file. I wonder:
- if it's a good approach to do that;
- the emf persistence framework provides a built-in feature to do that;
- if not, how to extend this layer to add such feature.
Thanks very much for your help!
Thierry
|
|
| |
Re: Storing an ecore model into several files [message #535673 is a reply to message #535661] |
Tue, 25 May 2010 08:29 |
|
Am 25.05.2010 10:10, schrieb Stefan Winkler:
> Thierry,
>
>
>> I try to store an ecore model within several files in order to prevent
>> from having one big file.
>>
> you can do this for elements referenced by EReferences that have
> container set to false.
> Then you can either set the proxy-property which causes the sub-model to
> be loaded lazily, or you can let it be set to false, in which case the
> whole model is loaded from multiple files at once.
>
> The problem is that you can only unload a sub-model explicitly.
How? The idea that Resource.unload() frees any memory is an illusion.
Compare
http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> So if
> your whole model does not fit into your memory, you would be better off
> using something like CDO.
>
> Generally, EMF provides the EStore API which you can (IIRC) use to plug
> your own storage mechanism at a model-element basis.
> The CDO project exposes this API in order to provide a flexible
> distributed model storage mechanism (among other things). Depending on
> your requirements, this could also be a choice for your project.
>
> Cheers,
> Stefan
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: Storing an ecore model into several files [message #535674 is a reply to message #535661] |
Tue, 25 May 2010 08:31 |
Eclipse User |
|
|
|
Originally posted by: templth.yahoo.fr
Hello Stefan,
Thanks very much for your answer!
> Thierry,
>
>> [...]
>
> you can do this for elements referenced by EReferences that have
> container set to false.
If I properly understand, only setting the property to false makes EMF
store the model into several files or is there something else to be done?
> Then you can either set the proxy-property which causes the sub-model to
> be loaded lazily, or you can let it be set to false, in which case the
> whole model is loaded from multiple files at once.
Ok
> The problem is that you can only unload a sub-model explicitly. So if
> your whole model does not fit into your memory, you would be better off
> using something like CDO.
So we need to split the model into parts by hands and link them using
"Load Resource" or something like that?
> Generally, EMF provides the EStore API which you can (IIRC) use to plug
> your own storage mechanism at a model-element basis.
Can you give me some hints on how to plug custom implementation of
EStore? is it done through a dedicated extension point?
> The CDO project exposes this API in order to provide a flexible
> distributed model storage mechanism (among other things). Depending on
> your requirements, this could also be a choice for your project.
Thanks for the hint, I'll have a look!
> Cheers,
> Stefan
Thanks very much,
Cheers,
Thierry
|
|
| |
Re: Storing an ecore model into several files [message #535686 is a reply to message #535674] |
Tue, 25 May 2010 09:13 |
Stefan Winkler Messages: 307 Registered: July 2009 Location: Germany |
Senior Member |
|
|
Hi Thierry,
comments below.
>> you can do this for elements referenced by EReferences that have
>> container set to false.
>
> If I properly understand, only setting the property to false makes EMF
> store the model into several files or is there something else to be done?
Well not exactly. Setting the container property to false makes EMF to
NOT store the referenced element the the same file.
Meaning: you have to additionally add the referenced (non-contained)
element to an own resource (and this is your other file).
>
>> Then you can either set the proxy-property which causes the sub-model to
>> be loaded lazily, or you can let it be set to false, in which case the
>> whole model is loaded from multiple files at once.
>
> Ok
>
>> The problem is that you can only unload a sub-model explicitly. So if
>> your whole model does not fit into your memory, you would be better off
>> using something like CDO.
>
> So we need to split the model into parts by hands and link them using
> "Load Resource" or something like that?
Well, the property applies to the (meta-)model. If your model is, e.g.
library
section
book
book
section
book
and you decide to make the section->book reference non-contained, then
you have to declare this in the .ecore-file.
As a consequence you need the program logic (as explained above) that
stores every book in a single separate resource.
In the file which stores the library, references to the books are stored
including the referenced file name. So, loading can be done by EMF.
Only the code to store the books into separate files has to be done by you.
Oh, and as Eike said, theoretically, you can unload single books, but
this does not necessarily free memory.
>> your own storage mechanism at a model-element basis.
> Generally, EMF provides the EStore API which you can (IIRC) use to plug
>
> Can you give me some hints on how to plug custom implementation of
> EStore? is it done through a dedicated extension point?
Eike answered that one already.
Cheers,
Stefan
|
|
| |
Re: Storing an ecore model into several files [message #535704 is a reply to message #535686] |
Tue, 25 May 2010 10:10 |
Eclipse User |
|
|
|
Originally posted by: templth.yahoo.fr
Hi Stefan,
I also see the approach. It seems that there are some additional work to
do ;-)
If I understand well, you must add the element within a specific and
imported file and then reference it as a non contained element. Am I
right? Is it the correct order? I assume that there isn't a all-in-one
operation to do that...
Thanks very much for your help!
Thierry
> Hi Thierry,
>
> comments below.
>
>>> you can do this for elements referenced by EReferences that have
>>> container set to false.
>> If I properly understand, only setting the property to false makes EMF
>> store the model into several files or is there something else to be done?
> Well not exactly. Setting the container property to false makes EMF to
> NOT store the referenced element the the same file.
> Meaning: you have to additionally add the referenced (non-contained)
> element to an own resource (and this is your other file).
>
>>> Then you can either set the proxy-property which causes the sub-model to
>>> be loaded lazily, or you can let it be set to false, in which case the
>>> whole model is loaded from multiple files at once.
>> Ok
>>
>>> The problem is that you can only unload a sub-model explicitly. So if
>>> your whole model does not fit into your memory, you would be better off
>>> using something like CDO.
>> So we need to split the model into parts by hands and link them using
>> "Load Resource" or something like that?
>
> Well, the property applies to the (meta-)model. If your model is, e.g.
> library
> section
> book
> book
> section
> book
>
> and you decide to make the section->book reference non-contained, then
> you have to declare this in the .ecore-file.
> As a consequence you need the program logic (as explained above) that
> stores every book in a single separate resource.
>
> In the file which stores the library, references to the books are stored
> including the referenced file name. So, loading can be done by EMF.
> Only the code to store the books into separate files has to be done by you.
>
> Oh, and as Eike said, theoretically, you can unload single books, but
> this does not necessarily free memory.
>
>>> your own storage mechanism at a model-element basis.
>> Generally, EMF provides the EStore API which you can (IIRC) use to plug
>>
>> Can you give me some hints on how to plug custom implementation of
>> EStore? is it done through a dedicated extension point?
> Eike answered that one already.
>
> Cheers,
> Stefan
>
>
>
|
|
|
Re: Storing an ecore model into several files [message #535707 is a reply to message #535704] |
Tue, 25 May 2010 10:57 |
Ed Merks Messages: 33137 Registered: July 2009 |
Senior Member |
|
|
Guys,
Note that even containment references allow cross resource support; you
have to ensure the resolveProxies is true and that the GenModel's
Containment Proxies property is set to true as well (so that the
generator respects the resolveProxies flags on the containment references).
Thierry Templier wrote:
> Hi Stefan,
>
> I also see the approach. It seems that there are some additional work
> to do ;-)
>
> If I understand well, you must add the element within a specific and
> imported file and then reference it as a non contained element. Am I
> right? Is it the correct order? I assume that there isn't a all-in-one
> operation to do that...
>
> Thanks very much for your help!
> Thierry
>
>> Hi Thierry,
>>
>> comments below.
>>
>>>> you can do this for elements referenced by EReferences that have
>>>> container set to false.
>>> If I properly understand, only setting the property to false makes EMF
>>> store the model into several files or is there something else to be
>>> done?
>> Well not exactly. Setting the container property to false makes EMF to
>> NOT store the referenced element the the same file.
>> Meaning: you have to additionally add the referenced (non-contained)
>> element to an own resource (and this is your other file).
>>
>>>> Then you can either set the proxy-property which causes the
>>>> sub-model to
>>>> be loaded lazily, or you can let it be set to false, in which case the
>>>> whole model is loaded from multiple files at once.
>>> Ok
>>>
>>>> The problem is that you can only unload a sub-model explicitly. So if
>>>> your whole model does not fit into your memory, you would be better
>>>> off
>>>> using something like CDO.
>>> So we need to split the model into parts by hands and link them using
>>> "Load Resource" or something like that?
>>
>> Well, the property applies to the (meta-)model. If your model is, e.g.
>> library
>> section
>> book
>> book section
>> book
>>
>> and you decide to make the section->book reference non-contained, then
>> you have to declare this in the .ecore-file.
>> As a consequence you need the program logic (as explained above) that
>> stores every book in a single separate resource.
>>
>> In the file which stores the library, references to the books are stored
>> including the referenced file name. So, loading can be done by EMF.
>> Only the code to store the books into separate files has to be done
>> by you.
>>
>> Oh, and as Eike said, theoretically, you can unload single books, but
>> this does not necessarily free memory.
>>
>>>> your own storage mechanism at a model-element basis.
>>> Generally, EMF provides the EStore API which you can (IIRC) use to plug
>>>
>>> Can you give me some hints on how to plug custom implementation of
>>> EStore? is it done through a dedicated extension point?
>> Eike answered that one already.
>>
>> Cheers,
>> Stefan
>>
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Re: Storing an ecore model into several files [message #535767 is a reply to message #535707] |
Tue, 25 May 2010 14:20 |
Eclipse User |
|
|
|
Originally posted by: templth.yahoo.fr
Thanks very much for the hint, Ed.
Thierry
> Guys,
>
> Note that even containment references allow cross resource support; you
> have to ensure the resolveProxies is true and that the GenModel's
> Containment Proxies property is set to true as well (so that the
> generator respects the resolveProxies flags on the containment references).
>
>
> Thierry Templier wrote:
>> Hi Stefan,
>>
>> I also see the approach. It seems that there are some additional work
>> to do ;-)
>>
>> If I understand well, you must add the element within a specific and
>> imported file and then reference it as a non contained element. Am I
>> right? Is it the correct order? I assume that there isn't a all-in-one
>> operation to do that...
>>
>> Thanks very much for your help!
>> Thierry
>>
>>> Hi Thierry,
>>>
>>> comments below.
>>>
>>>>> you can do this for elements referenced by EReferences that have
>>>>> container set to false.
>>>> If I properly understand, only setting the property to false makes EMF
>>>> store the model into several files or is there something else to be
>>>> done?
>>> Well not exactly. Setting the container property to false makes EMF to
>>> NOT store the referenced element the the same file.
>>> Meaning: you have to additionally add the referenced (non-contained)
>>> element to an own resource (and this is your other file).
>>>
>>>>> Then you can either set the proxy-property which causes the
>>>>> sub-model to
>>>>> be loaded lazily, or you can let it be set to false, in which case the
>>>>> whole model is loaded from multiple files at once.
>>>> Ok
>>>>
>>>>> The problem is that you can only unload a sub-model explicitly. So if
>>>>> your whole model does not fit into your memory, you would be better
>>>>> off
>>>>> using something like CDO.
>>>> So we need to split the model into parts by hands and link them using
>>>> "Load Resource" or something like that?
>>>
>>> Well, the property applies to the (meta-)model. If your model is, e.g.
>>> library
>>> section
>>> book
>>> book section
>>> book
>>>
>>> and you decide to make the section->book reference non-contained, then
>>> you have to declare this in the .ecore-file.
>>> As a consequence you need the program logic (as explained above) that
>>> stores every book in a single separate resource.
>>>
>>> In the file which stores the library, references to the books are stored
>>> including the referenced file name. So, loading can be done by EMF.
>>> Only the code to store the books into separate files has to be done
>>> by you.
>>>
>>> Oh, and as Eike said, theoretically, you can unload single books, but
>>> this does not necessarily free memory.
>>>
>>>>> your own storage mechanism at a model-element basis.
>>>> Generally, EMF provides the EStore API which you can (IIRC) use to plug
>>>>
>>>> Can you give me some hints on how to plug custom implementation of
>>>> EStore? is it done through a dedicated extension point?
>>> Eike answered that one already.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
|
|
| | |
Goto Forum:
Current Time: Sat Apr 20 02:30:19 GMT 2024
Powered by FUDForum. Page generated in 0.03735 seconds
|