Home » Modeling » EMF » Problem with cross-document serialization
| Problem with cross-document serialization [message #428202] |
Fri, 13 March 2009 15:21  |
Eclipse User |
|
|
|
Originally posted by: ptrinchini.quipo.it
Hi All,
I'm quite new to EMF and I would have an expert advice on which is the
best way to manage cross document references when saving a model
instance programmatically.
My model is defined in multiple .ecore files, each file has only one
package. When I create an instance of it, I create objects from
different packages, using the appropriate factory; when it comes to
serialize the model instance, I create a ResourceSet and register on its
PackageRegistry all the packages I used, then I ask the ResourceSet to
create a Resource for my model (giving it the URI of the file that must
contain the serialized instance) and I add my model instance to the
resource contents. When I call save(null) on the resource, I get several
exception saying that objects defined in other .ecore models are not
contained in a resource. However, if I explicitly add them to the
resource, the save works, but when I open the model instance in the
generated EMF editor, I see those objects also under the root of the
tree, not only where they are defined within the model (e.g. if I've a
1:* non-containment relation between class A and class B, I see the set
of B instances under A, but also under the root of the tree)
Reading the second edition of the EMF book, I learned that
cross-document references are handled correctly by the framework if the
model is saved after all the objects have been added to the respective
resource, is this the solution to my problem?
Thanks a lot for your help!
Regards,
Patrizio
model whose instances are backed by multiple resources, i.e. the model
is described in more .ecore files
|
|
|
| Re: Problem with cross-document serialization [message #428203 is a reply to message #428202] |
Fri, 13 March 2009 16:16  |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Patrizio,
Comments below.
Patrizio wrote:
> Hi All,
>
> I'm quite new to EMF and I would have an expert advice on which is the
> best way to manage cross document references when saving a model
> instance programmatically.
> My model is defined in multiple .ecore files, each file has only one
> package. When I create an instance of it, I create objects from
> different packages, using the appropriate factory; when it comes to
> serialize the model instance, I create a ResourceSet and register on
> its PackageRegistry all the packages I used, then I ask the
> ResourceSet to create a Resource for my model (giving it the URI of
> the file that must contain the serialized instance) and I add my model
> instance to the resource contents. When I call save(null) on the
> resource, I get several exception saying that objects defined in other
> .ecore models are not contained in a resource. However, if I
> explicitly add them to the resource, the save works, but when I open
> the model instance in the generated EMF editor, I see those objects
> also under the root of the tree, not only where they are defined
> within the model (e.g. if I've a 1:* non-containment relation between
> class A and class B, I see the set of B instances under A, but also
> under the root of the tree)
>
> Reading the second edition of the EMF book, I learned that
> cross-document references are handled correctly by the framework if
> the model is saved after all the objects have been added to the
> respective resource, is this the solution to my problem?
Yes. An object x for which x.eResource() == null can't be serialized.
Not even a reference to it can be serialized. In order for
x.eResource() to not be null either x has be to added to
resource.getContents(), or x needs to be added/set to a containment
reference of some object y where y.eResource() != null. And of course
that definition is recursive. So if you expect an object to be
serialized nested under some parent, then you need to make that a
containment reference.
>
> Thanks a lot for your help!
>
> Regards,
> Patrizio
>
>
>
>
>
>
>
>
> model whose instances are backed by multiple resources, i.e. the model
> is described in more .ecore files
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with cross-document serialization [message #428206 is a reply to message #428203] |
Fri, 13 March 2009 17:08 |
| Eclipse User |
|
|
|
Originally posted by: ptrinchini.quipo.it
Ed Merks wrote:
> Patrizio,
>
> Comments below.
>
>
> Patrizio wrote:
>> Hi All,
>>
>> I'm quite new to EMF and I would have an expert advice on which is the
>> best way to manage cross document references when saving a model
>> instance programmatically.
>> My model is defined in multiple .ecore files, each file has only one
>> package. When I create an instance of it, I create objects from
>> different packages, using the appropriate factory; when it comes to
>> serialize the model instance, I create a ResourceSet and register on
>> its PackageRegistry all the packages I used, then I ask the
>> ResourceSet to create a Resource for my model (giving it the URI of
>> the file that must contain the serialized instance) and I add my model
>> instance to the resource contents. When I call save(null) on the
>> resource, I get several exception saying that objects defined in other
>> .ecore models are not contained in a resource. However, if I
>> explicitly add them to the resource, the save works, but when I open
>> the model instance in the generated EMF editor, I see those objects
>> also under the root of the tree, not only where they are defined
>> within the model (e.g. if I've a 1:* non-containment relation between
>> class A and class B, I see the set of B instances under A, but also
>> under the root of the tree)
>>
>> Reading the second edition of the EMF book, I learned that
>> cross-document references are handled correctly by the framework if
>> the model is saved after all the objects have been added to the
>> respective resource, is this the solution to my problem?
> Yes. An object x for which x.eResource() == null can't be serialized.
> Not even a reference to it can be serialized. In order for
> x.eResource() to not be null either x has be to added to
> resource.getContents(), or x needs to be added/set to a containment
> reference of some object y where y.eResource() != null. And of course
> that definition is recursive. So if you expect an object to be
> serialized nested under some parent, then you need to make that a
> containment reference.
>>
>> Thanks a lot for your help!
>>
>> Regards,
>> Patrizio
>>
>>
>>
>>
>>
>>
>>
>>
>> model whose instances are backed by multiple resources, i.e. the model
>> is described in more .ecore files
Ed,
thanks a lot for your prompt response, and also for your excellent book!
the topic is complex and it really helps to smooth the learning curve.
Following your suggestion, I changed all the relations in the model to
be containment references and now, when I serialize the instance of the
model it works and in the editor I see only one copy of the objects.
However I'm wandering if what I would achieve can be obtained without
changing the semantic of the model. I mean, is it possible to add all
the objects involved in the model in a single resource and then have the
generated editor show only one copy of them?
Let me better explain with an example. Assume that class A aggregates
multiple instances of a class B, which is shared among other classes in
the model and is defined in its own ecore model [A ----(*)-> B]; in
order to have B correctly serialized, I undertand that it must be added
to the contents of a resource; if I add it to the content of the same
resource that contains A (so that both will be persisted in the same XMI
file), the generated editor show the following tree:
A instance
->Set
-> B instance
-> B another instance
B instance
B another instance
I would like to suppress the nodes of B instances at the root level. Is
it possible? should I somehow change the EditingDomain ?
Thanks again for your help
Regards,
Patrizio
|
|
|
| Re: Problem with cross-document serialization [message #428208 is a reply to message #428206] |
Fri, 13 March 2009 18:14 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Patrizio,
Comments below.
Patrizio wrote:
> Ed Merks wrote:
>> Patrizio,
>>
>> Comments below.
>>
>>
>> Patrizio wrote:
>>> Hi All,
>>>
>>> I'm quite new to EMF and I would have an expert advice on which is
>>> the best way to manage cross document references when saving a model
>>> instance programmatically.
>>> My model is defined in multiple .ecore files, each file has only one
>>> package. When I create an instance of it, I create objects from
>>> different packages, using the appropriate factory; when it comes to
>>> serialize the model instance, I create a ResourceSet and register on
>>> its PackageRegistry all the packages I used, then I ask the
>>> ResourceSet to create a Resource for my model (giving it the URI of
>>> the file that must contain the serialized instance) and I add my
>>> model instance to the resource contents. When I call save(null) on
>>> the resource, I get several exception saying that objects defined in
>>> other .ecore models are not contained in a resource. However, if I
>>> explicitly add them to the resource, the save works, but when I open
>>> the model instance in the generated EMF editor, I see those objects
>>> also under the root of the tree, not only where they are defined
>>> within the model (e.g. if I've a 1:* non-containment relation
>>> between class A and class B, I see the set of B instances under A,
>>> but also under the root of the tree)
>>>
>>> Reading the second edition of the EMF book, I learned that
>>> cross-document references are handled correctly by the framework if
>>> the model is saved after all the objects have been added to the
>>> respective resource, is this the solution to my problem?
>> Yes. An object x for which x.eResource() == null can't be
>> serialized. Not even a reference to it can be serialized. In order
>> for x.eResource() to not be null either x has be to added to
>> resource.getContents(), or x needs to be added/set to a containment
>> reference of some object y where y.eResource() != null. And of
>> course that definition is recursive. So if you expect an object to
>> be serialized nested under some parent, then you need to make that a
>> containment reference.
>>>
>>> Thanks a lot for your help!
>>>
>>> Regards,
>>> Patrizio
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> model whose instances are backed by multiple resources, i.e. the
>>> model is described in more .ecore files
> Ed,
>
> thanks a lot for your prompt response, and also for your excellent
> book! the topic is complex and it really helps to smooth the learning
> curve.
> Following your suggestion, I changed all the relations in the model to
> be containment references and now, when I serialize the instance of
> the model it works and in the editor I see only one copy of the objects.
:-)
>
> However I'm wandering if what I would achieve can be obtained without
> changing the semantic of the model. I mean, is it possible to add all
> the objects involved in the model in a single resource and then have
> the generated editor show only one copy of them?
It's definitely possible to put all your objects at the root of one ore
more resources and have no containment references at all. Containment
is an important concept that you need to consider designing carefully...
>
> Let me better explain with an example. Assume that class A aggregates
> multiple instances of a class B, which is shared among other classes
> in the model and is defined in its own ecore model [A ----(*)-> B]; in
> order to have B correctly serialized, I undertand that it must be
> added to the contents of a resource; if I add it to the content of the
> same resource that contains A (so that both will be persisted in the
> same XMI file), the generated editor show the following tree:
>
> A instance
> ->Set
> -> B instance
> -> B another instance
> B instance
> B another instance
Yes.
>
> I would like to suppress the nodes of B instances at the root level.
> Is it possible?
You can specialize what the ResourceItemProvider shows as children.
An important question that will arise is what happens when you delete a
"B". Does it just remove A's reference to B or does it really delete B
along with all references to it?
Another possible design is to have A support "ownedBs" as wells as
"sharedBs". I'm not sure if that makes sense for what A and B really
are though...
> should I somehow change the EditingDomain ?
>
> Thanks again for your help
>
> Regards,
> Patrizio
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with cross-document serialization [message #428214 is a reply to message #428208] |
Fri, 13 March 2009 22:42 |
| Eclipse User |
|
|
|
Originally posted by: ptrinchini.quipo.it
Ed Merks wrote:
> Patrizio,
>
> Comments below.
>
> Patrizio wrote:
>> Ed Merks wrote:
>>> Patrizio,
>>>
>>> Comments below.
>>>
>>>
>>> Patrizio wrote:
>>>> Hi All,
>>>>
>>>> I'm quite new to EMF and I would have an expert advice on which is
>>>> the best way to manage cross document references when saving a model
>>>> instance programmatically.
>>>> My model is defined in multiple .ecore files, each file has only one
>>>> package. When I create an instance of it, I create objects from
>>>> different packages, using the appropriate factory; when it comes to
>>>> serialize the model instance, I create a ResourceSet and register on
>>>> its PackageRegistry all the packages I used, then I ask the
>>>> ResourceSet to create a Resource for my model (giving it the URI of
>>>> the file that must contain the serialized instance) and I add my
>>>> model instance to the resource contents. When I call save(null) on
>>>> the resource, I get several exception saying that objects defined in
>>>> other .ecore models are not contained in a resource. However, if I
>>>> explicitly add them to the resource, the save works, but when I open
>>>> the model instance in the generated EMF editor, I see those objects
>>>> also under the root of the tree, not only where they are defined
>>>> within the model (e.g. if I've a 1:* non-containment relation
>>>> between class A and class B, I see the set of B instances under A,
>>>> but also under the root of the tree)
>>>>
>>>> Reading the second edition of the EMF book, I learned that
>>>> cross-document references are handled correctly by the framework if
>>>> the model is saved after all the objects have been added to the
>>>> respective resource, is this the solution to my problem?
>>> Yes. An object x for which x.eResource() == null can't be
>>> serialized. Not even a reference to it can be serialized. In order
>>> for x.eResource() to not be null either x has be to added to
>>> resource.getContents(), or x needs to be added/set to a containment
>>> reference of some object y where y.eResource() != null. And of
>>> course that definition is recursive. So if you expect an object to
>>> be serialized nested under some parent, then you need to make that a
>>> containment reference.
>>>>
>>>> Thanks a lot for your help!
>>>>
>>>> Regards,
>>>> Patrizio
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> model whose instances are backed by multiple resources, i.e. the
>>>> model is described in more .ecore files
>> Ed,
>>
>> thanks a lot for your prompt response, and also for your excellent
>> book! the topic is complex and it really helps to smooth the learning
>> curve.
>> Following your suggestion, I changed all the relations in the model to
>> be containment references and now, when I serialize the instance of
>> the model it works and in the editor I see only one copy of the objects.
> :-)
>>
>> However I'm wandering if what I would achieve can be obtained without
>> changing the semantic of the model. I mean, is it possible to add all
>> the objects involved in the model in a single resource and then have
>> the generated editor show only one copy of them?
> It's definitely possible to put all your objects at the root of one ore
> more resources and have no containment references at all. Containment
> is an important concept that you need to consider designing carefully...
>>
>> Let me better explain with an example. Assume that class A aggregates
>> multiple instances of a class B, which is shared among other classes
>> in the model and is defined in its own ecore model [A ----(*)-> B]; in
>> order to have B correctly serialized, I undertand that it must be
>> added to the contents of a resource; if I add it to the content of the
>> same resource that contains A (so that both will be persisted in the
>> same XMI file), the generated editor show the following tree:
>>
>> A instance
>> ->Set
>> -> B instance
>> -> B another instance
>> B instance
>> B another instance
> Yes.
>>
>> I would like to suppress the nodes of B instances at the root level.
>> Is it possible?
> You can specialize what the ResourceItemProvider shows as children.
> An important question that will arise is what happens when you delete a
> "B". Does it just remove A's reference to B or does it really delete B
> along with all references to it?
>
> Another possible design is to have A support "ownedBs" as wells as
> "sharedBs". I'm not sure if that makes sense for what A and B really
> are though...
>> should I somehow change the EditingDomain ?
>>
>> Thanks again for your help
>>
>> Regards,
>> Patrizio
>>
>>
>>
>>
Ed,
thanks again for your help! following your suggestion, I implemented a
custom ResourceItemProvider that is served by a custom factory used to
initialize the editing domain of my editor; the custom implementation
simply iterates over the collection of objects returned by the default
implementation and skip all except the object I want to display as the
single root of the tree (an object of type A in my previous post). In
this way, even if I add multiple objects to the contents of the resource
the editor is displaying, with the objective to have them serialized in
a single file, only the relevant object is displayed.
Hope what I did is what really you suggested ;-) please, correct me if not.
About the other option you mentioned, I don't know much about "ownedBs"
and "sharedBs" support, so I cannot say if the could be appropriate in
my case; I will look at this and try to understand if they offer a
better solution to my problem directly in the modeling domain.
Have a nice WE!
Bye,
Patrizio
|
|
|
Goto Forum:
Current Time: Tue Apr 23 07:07:40 GMT 2024
Powered by FUDForum. Page generated in 0.03463 seconds |
] 
Search
Help
Register
Login
Home
