I am trying to save a model using the EMF Resource tools. The root node essentially writes out the data correctly, but within there is an underlying containment to two other "reference" objects. These objects share the same eResource as it's parent, and the containment is true. After saving i viewed the xml file, expecting to see the data written out from each of these "references". but instead they both look similar to this:

Just a note, I did figure out the problem. When saving, the inner References had an eResource different than the container. But even if they were the same, it would still save out incorrectly. So what i did was i cleared the eResource for each of the inner contained references. This then allowed the parent container to write out the data contained in each of the references. It seems to me like if it has an eResource, that it writes out to that, rather than being written with it's parent when saved. I am probably wrong, but that's what my observation was. Thanks though! This was my first post. Maybe it will help someone else

There is support for cross resource containment so indeed, if a
contained object is directly contained in some other resource or even
the same resource, it will be serialized much like a cross reference,
i.e., by referencing the object where it is contained as the root object
of some resource.

On 25/04/2013 9:06 PM, Nick Staudt wrote:
> Just a note, I did figure out the problem. When saving, the inner
> References had an eResource different than the container. But even if
> they were the same, it would still save out incorrectly. So what i did
> was i cleared the eResource for each of the inner contained
> references. This then allowed the parent container to write out the
> data contained in each of the references. It seems to me like if it
> has an eResource, that it writes out to that, rather than being
> written with it's parent when saved. I am probably wrong, but that's
> what my observation was. Thanks though! This was my first post. Maybe
> it will help someone else
>
> Nick

Is there a way to force proxies to be resolved upon serializing out a Resource? Nick's approach, though it works, seems like it's going about it the wrong way.

For example, we have a usecase where we have to load a model from a database (Model A), attach it to another model (Model B), and save it to a server from which a third party can reload it. Upon reload, we don't care if Model A and Model B are contained by the same Resource.

On 01/05/2013 2:44 PM, Ian Price wrote:
> Ed,
>
> Is there a way to force proxies to be resolved upon serializing out a
> Resource?
I'm not sure what you mean... It's never necessary to resolve proxy as
part of serialization, so what's gained from that? EcoreUtil.resolveAll
can be used to force proxies to resolve in general...
> Nick's approach, though it works, seems like it's going about it the
> wrong way.
>
> For example, we have a usecase where we have to load a model from a
> database (Model A), attach it to another model (Model B), and save it
> to a server from which a third party can reload it. Upon reload, we
> don't care if Model A and Model B are contained by the same Resource.
Having models that span resources is common. That's what proxies are
for. Normally proxies are resolved as you traverse them, so it's all
transparent. So I'm not sure what problem you're trying to solve. In
any case, EcoreUtil.resolveAll is a brute force way to resolve all
proxies up front, i.e., you can apply it to a resource set and be
assured that the resource set contains all reachable resources and any
proxy that can be resolved, has been resolved.
> V/r,
> -Ian