| XMLSaveImpl not saving data [message #515723] |
Fri, 19 February 2010 17:50  |
 Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hello,
I think I've found a bug with EMF's XMLSaveImpl class. I have a model with two class in it that
have a containment and opposite relationship. I'm also saving the parent and child in different
resources, so they will be saved with a cross-document URI. The child also has a list of references
to sub-children that is also saved in other documents (again cross-document URIs). The model allows
for containment proxies.
Because of the child's relationship to its parent is eOpposite and the parent is containment, the
"kind" is set to 0 (or Transient, although it isn't really transient) in
XMLSaveImp$Lookup.featureKind(), so it won't save the feature in the LOOP in
XMLSaveImpl.saveFeatures(). However, if there are not any sub-children, then elementFeatures in
XMLSaveImpl.saveFeatures() will be null. If elementFeatures is null, then
XMLSaveImpl.saveFeatures() will actually save the reference to the parent by calling
writeTopElements(root) on line 1443:
if (elementFeatures == null)
{
if (content == null)
{
content = getContent(o, features);
}
if (content == null)
{
if (o == root && writeTopElements(root))
This works out well, because if we load the child by itself, it has a reference to its parent as it
should.
However, if the child has sub-children, then elementFeatures is set inside the LOOP because case
OBJECT_CONTAIN_MANY falls through the case statement. This is done so it can save the URIs pointing
to those sub-children later. But since elementFeatures is not null, it won't call
writeTopElements(root) on line 1443, so it won't save the parent pointer. This is bad because if we
load the child by itself, it will have a null parent instead of a proxy pointing to a different
resource.
Is this really a bug with XMLSaveImpl or am I missing something here?
Thanks in advance.
Sincerely,
Stephen McCants
|
|
|
| Re: XMLSaveImpl not saving data [message #515728 is a reply to message #515723] |
Fri, 19 February 2010 18:33  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
Stephen McCants wrote:
> Hello,
> I think I've found a bug with EMF's XMLSaveImpl class. I have a
> model with two class in it that have a containment and opposite
> relationship. I'm also saving the parent and child in different
> resources, so they will be saved with a cross-document URI. The child
> also has a list of references to sub-children that is also saved in
> other documents (again cross-document URIs). The model allows for
> containment proxies.
> Because of the child's relationship to its parent is eOpposite and
> the parent is containment, the "kind" is set to 0 (or Transient,
> although it isn't really transient) in
> XMLSaveImp$Lookup.featureKind(), so it won't save the feature in the
> LOOP in XMLSaveImpl.saveFeatures(). However, if there are not any
> sub-children, then elementFeatures in XMLSaveImpl.saveFeatures() will
> be null. If elementFeatures is null, then XMLSaveImpl.saveFeatures()
> will actually save the reference to the parent by calling
> writeTopElements(root) on line 1443:
>
> if (elementFeatures == null)
> {
> if (content == null)
> {
> content = getContent(o, features);
> }
>
> if (content == null)
> {
> if (o == root && writeTopElements(root))
>
> This works out well, because if we load the child by itself, it has a
> reference to its parent as it should.
> However, if the child has sub-children, then elementFeatures is
> set inside the LOOP because case OBJECT_CONTAIN_MANY falls through the
> case statement. This is done so it can save the URIs pointing to
> those sub-children later. But since elementFeatures is not null, it
> won't call writeTopElements(root) on line 1443, so it won't save the
> parent pointer.
Why doesn't this get called? (At 1481 in HEAD.)
if (o == root)
{
writeTopElements(root);
}
> This is bad because if we load the child by itself, it will have a
> null parent instead of a proxy pointing to a different resource.
> Is this really a bug with XMLSaveImpl or am I missing something here?
It might well be, but it looks to me like writeTopElements is always
called for the root object except when it only has simple content. If
you're quite sure it's a problem please open a bugzilla with a test case
and I'll look into it ASAP.
> Thanks in advance.
>
> Sincerely,
> Stephen McCants
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02761 seconds
] 
Search
Help
Register
Login
Home
