Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Persistence of Multiplicity-Many Reference
Persistence of Multiplicity-Many Reference [message #505613] Sun, 03 January 2010 15:09 Go to next message
Nidhi  is currently offline Nidhi Friend
Messages: 92
Registered: December 2009
Member

Hi,

I am generating the Ecore mode from an XSD schema.

If I define my XSD schema as follows:

<xsd:complexType name="MyClass">
<xsd:sequence>
...
<xsd:element name="dependencies" minOccurs="0" >
<xsd:complexType>
<xsd:sequence>
<xsd:element name="dependency" type="test:Dependency" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
</xsd:sequence>
</xsd:complexType>

This creates an unnnecessary hierarchy in my ecore:

MyClass
dependencies: DependenciesType

DependeniesType
dependency: Dependency

However, this leads to the desired persistence format:
<myClass>
<dependencies>
<dependency name="a"/>
<dependency name="b"/>
</dependencies>
</myClass>

Now, I want to remove the unnecessary hierarchy and still mentain the same persistence as above. I managed to remove the hierarchy by modifying the XSD schema as:

<xsd:complexType name="MyClass">
<xsd:sequence>
...
<xsd:element name="dependencies" type="test:Dependency" minOccurs="0" maxOccurs="unbounded"/>
...
</xsd:sequence>
</xsd:complexType>

However, the persistence also changes to an undesired one:
<myClass>
<dependency name="a"/>
<dependency name="b"/>
</myClass>

I wanted to know if it is possible to remove the unneceesary hieracrchy in the ecore (as in the latter case) and still maintain the persistence in the former case above.

Thanks a lot in advance,
Nidhi




Re: Persistence of Multiplicity-Many Reference [message #505614 is a reply to message #505613] Sun, 03 January 2010 15:36 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Nidhi,

Unfortunately we've not found the time to complete the implementation of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201662


Nidhi wrote:
> Hi,
>
> I am generating the Ecore mode from an XSD schema.
>
> If I define my XSD schema as follows:
>
> <xsd:complexType name="MyClass">
> <xsd:sequence>
> ...
> <xsd:element name="dependencies" minOccurs="0" >
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="dependency" type="test:Dependency"
> minOccurs="0" maxOccurs="unbounded" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> ...
> </xsd:sequence>
> </xsd:complexType>
>
> This creates an unnnecessary hierarchy in my ecore:
>
> MyClass
> dependencies: DependenciesType
>
> DependeniesType
> dependency: Dependency
>
> However, this leads to the desired persistence format:
> <myClass>
> <dependencies>
> <dependency name="a"/>
> <dependency name="b"/>
> </dependencies>
> </myClass>
>
> Now, I want to remove the unnecessary hierarchy and still mentain the
> same persistence as above. I managed to remove the hierarchy by
> modifying the XSD schema as:
>
> <xsd:complexType name="MyClass">
> <xsd:sequence>
> ...
> <xsd:element name="dependencies" type="test:Dependency"
> minOccurs="0" maxOccurs="unbounded"/>
> ...
> </xsd:sequence>
> </xsd:complexType>
>
> However, the persistence also changes to an undesired one:
> <myClass>
> <dependency name="a"/>
> <dependency name="b"/>
> </myClass>
>
> I wanted to know if it is possible to remove the unneceesary
> hieracrchy in the ecore (as in the latter case) and still maintain the
> persistence in the former case above.
>
> Thanks a lot in advance,
> Nidhi
>
>
>
>
>
Re: Persistence of Multiplicity-Many Reference [message #505615 is a reply to message #505613] Sun, 03 January 2010 16:28 Go to previous messageGo to next message
Nidhi  is currently offline Nidhi Friend
Messages: 92
Registered: December 2009
Member

Hi Ed,

Thanks a lot for a quick reply.
I went through the bug, but have have couple of questions/confusions:

"If there is a single repeating element, I think it should be possible to avoid
the extra class creation:"


I quiet didn't get this point, how would it be possible to avoid the extra class?

"In XMLHandler (or descendant), I keep a list of "deferredReferences" and a
list<Integer> of deferredLevels in order to process the "extra" wrapper
elements without creating unexistant features. "objects" and "types" must be
handled so that everything looks OK. It is more complex than in XMLSaveImpl,
but only impacts handleFeature and endElement."


Could you please elaborate, I am sorry but I am not very fluent in EMF :( , might
need some more elaboration to get this right.


Also, I tried using ecore:ignore="true" for my anonymous complex type:

<xsd:element name="dependencies" minOccurs="0" >
<xsd:complexType ecore:ignore="true">
<xsd:sequence>
<xsd:element name="dependency" type="test:Dependency" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

However, the ecore generated does still creates an extra class. Am I missing something here.

Best Regards,
Nidhi
Re: Persistence of Multiplicity-Many Reference [message #505616 is a reply to message #505615] Sun, 03 January 2010 17:37 Go to previous messageGo to next message
Nidhi  is currently offline Nidhi Friend
Messages: 92
Registered: December 2009
Member

Hi Ed,

I am sorry, I skipped the fact that it was a discussion of implementation in process.

However, I wanted to know if there is a work around to this problem. Would using XMLMap (OPTION_XML_MAP) help.

Best Regards,
Nidhi
Re: Persistence of Multiplicity-Many Reference [message #505621 is a reply to message #505615] Sun, 03 January 2010 14:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Nidhi,

Comments below.

Nidhi wrote:
> Hi Ed,
>
> Thanks a lot for a quick reply.
> I went through the bug, but have have couple of questions/confusions:
>
> "If there is a single repeating element, I think it should be possible
> to avoid
> the extra class creation:"
>
> I quiet didn't get this point, how would it be possible to avoid the
> extra class?
That' exactly your comment: "this creates an unnecessary hierarchy in my
ecore." The intermediate instance object serves only to carry a list
feature and it's the class for that object we want to avoid...
>
> "In XMLHandler (or descendant), I keep a list of "deferredReferences"
> and a
> list<Integer> of deferredLevels in order to process the "extra" wrapper
> elements without creating unexistant features. "objects" and "types"
> must be
> handled so that everything looks OK. It is more complex than in
> XMLSaveImpl,
> but only impacts handleFeature and endElement."
>
> Could you please elaborate, I am sorry but I am not very fluent in EMF
> :( , might need some more elaboration to get this right.
If I had more time it would all be committed and I'd not have to explain.
>
>
> Also, I tried using ecore:ignore="true" for my anonymous complex type:
>
> <xsd:element name="dependencies" minOccurs="0" >
> <xsd:complexType ecore:ignore="true">
> <xsd:sequence>
> <xsd:element name="dependency" type="test:Dependency"
> minOccurs="0" maxOccurs="unbounded" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
> However, the ecore generated does still creates an extra class. Am I
> missing something here.
You can ignore creating an element, but one you create the element, it's
type must be created.

The best I can do is point you at the bugzilla. It's really quite a
complex problem to solve and it would be eve more complex to try to
explain how to solve it to a relative novice. Sorry.
>
> Best Regards,
> Nidhi
Re: Persistence of Multiplicity-Many Reference [message #505622 is a reply to message #505621] Sun, 03 January 2010 19:15 Go to previous messageGo to next message
Nidhi  is currently offline Nidhi Friend
Messages: 92
Registered: December 2009
Member

Nevermind Ed :),

I did get a hang of the solution being discussed in the
reported bug after having a closer look at it.

I'll look for forward to the resolution, however, as of now am I correct to say that there can be 2 alternatives:

1. Use OPTION_XML_MAP to customize my serialization..
OR
2. Use WTP Translators..

Do you feel that either of them would be a good workaround?

Best Regards,
Nidhi



Re: Persistence of Multiplicity-Many Reference [message #505623 is a reply to message #505616] Sun, 03 January 2010 19:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Nidhi,

If there was a simple solution, I'd not have worked on a complex one. Sorry.

Some tricks you could play would be to set the unwanted intermediate
classes GenClass "Dynamic" property to true, so that no interface is
generated for it. Suppress the getters and setters for the intermediate
instance object from the public API. Add a hand written getter that
returns the list feature of the intermediate object, creating the
intermediate object (using EcoreUtil.create reflectively). The EMF
refcard is good for looking up how to do things like this.


Nidhi wrote:
> Hi Ed,
>
> I am sorry, I skipped the fact that it was a discussion of
> implementation in process.
>
> However, I wanted to know if there is a work around to this problem.
> Would using XMLMap (OPTION_XML_MAP) help.
> Best Regards,
> Nidhi
>
Re: Persistence of Multiplicity-Many Reference [message #505624 is a reply to message #505623] Sun, 03 January 2010 19:24 Go to previous messageGo to next message
Nidhi  is currently offline Nidhi Friend
Messages: 92
Registered: December 2009
Member

Thanks for the lead Ed.
I'll try this out.

Best Regards,
Nidhi
Re: Persistence of Multiplicity-Many Reference [message #505625 is a reply to message #505622] Sun, 03 January 2010 19:34 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Nidhi,

I don't think the map can cope with omitting intermediate levels of
objects. I don't know much about WTP translators, so I can't comment on
that.

Nidhi wrote:
> Nevermind Ed :),
>
> I did get a hang of the solution being discussed in the reported bug
> after having a closer look at it.
>
> I'll look for forward to the resolution, however, as of now am I
> correct to say that there can be 2 alternatives:
>
> 1. Use OPTION_XML_MAP to customize my serialization..
> OR
> 2. Use WTP Translators..
>
> Do you feel that either of them would be a good workaround?
>
> Best Regards,
> Nidhi
>
>
>
>
Previous Topic:Loading ecore model from a standalone java app
Next Topic:Reading ecore causes stack overflow
Goto Forum:
  


Current Time: Tue Nov 12 18:27:34 GMT 2019

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

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

Back to the top