Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Re: Getting n:m when I expect 1:n
Re: Getting n:m when I expect 1:n [message #112242] Mon, 11 February 2008 18:57 Go to next message
David Steinberg is currently offline David SteinbergFriend
Messages: 489
Registered: July 2009
Senior Member
Hi David,

Martin is correct in that the EFeatureMap-typed group is created to
represent the repeating model group. It is created whether the group is
a sequence, choice, or all, since any of those constructs could, in
general, require cross-feature order to be maintained.

Granted, it doesn't seem to buy you anything in this case, since there's
only one element inside the choice. But then, what's the purpose of the
choice at all? Removing the choice would produce a simpler structure
with just five features (when, instrumentIdentifier, source, other, id).

Cheers,
Dave


david wrote:
> Hi,
>
> This was on emft list, associated with Teneo. But since it is driven by
> the eCore generated model I assume it would be better here. Here is the
> discussion so far.
>
> The problem is that we end up with a "Feature group :
> EFeatureMapEntry" when it looks to me like we do not need one.
>
> Maybe I have to write some XSLT to alter the XSD to produce a construct
> that the ECore generator can work with?
>
> .....
>
> I think it is caused by the <xsd:choice minOccurs="0"
> maxOccurs="unbounded"> choice. Can you try something like this:
> <xsd:complexType name="CashDomain">
> <xsd:sequence>
> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
> <xsd:element ref="gensec:instrumentIdentifier" minOccurs="0"
> maxOccurs="unbounded"/>
> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
> </xsd:sequence>
> <xsd:attribute name="id" type="xsd:ID" use="optional" />
> </xsd:complexType>
> <xsd:element name="cashDomain" type="gensec:CashDomain" />
>
> btw, you can check if your change will result in a different mapping by
> looking at the generated java code, it should not generate a group
> member in CashDomain (at least not if you want 1:n).
>
>
>
> gr. Martin
>
> david wrote:
> > Martin,
> >
> > I am still not understanding the reason behind the n:m association
> generation when it appears to me to require 1:n.
> >
> > Say we have this
> >
> > <xsd:complexType name="CashDomain">
> > <xsd:sequence>
> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
> > <xsd:choice minOccurs="0" maxOccurs="unbounded">
> > <xsd:element ref="gensec:instrumentIdentifier" />
> > </xsd:choice>
> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
> > </xsd:sequence>
> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
> > </xsd:complexType>
> > <xsd:element name="cashDomain" type="gensec:CashDomain" />
> >
> >
> > And the gensec:instrumentIdentifier looks like this
> >
> > <xsd:complexType name="InstrumentIdentifier">
> > <xsd:sequence minOccurs="0" maxOccurs="1">
> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
> > <xsd:group minOccurs="0" maxOccurs="unbounded"
> ref="gensec:InstrumentIdentifier.children" />
> > <xsd:choice minOccurs="0" maxOccurs="1">
> > <xsd:element ref="gensec:source" />
> > </xsd:choice>
> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
> > </xsd:sequence>
> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
> > </xsd:complexType>
> > <xsd:element name="instrumentIdentifier"
> type="gensec:InstrumentIdentifier" />
> >
> > This looks like to me there is a 1:n relationship between cashDomain
> and instrumentIdentifier. But I end up with a n:m supported through a
> table called cashdomain_group.
> >
> > What can I do to the XSD to force a 1:n association in the database
> for these?
> >
> > David
Re: Getting n:m when I expect 1:n [message #112255 is a reply to message #112242] Tue, 12 February 2008 09:15 Go to previous message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

I agree entirely, the model is a standard ( mddl.org) that was designed
to be extensible and in fact therefore ignores a lot of real world
cardinality rules associated with the actual data. I am changing it to
reflect the real cardinality.

Thx.

David

Dave Steinberg wrote:
> Hi David,
>
> Martin is correct in that the EFeatureMap-typed group is created to
> represent the repeating model group. It is created whether the group is
> a sequence, choice, or all, since any of those constructs could, in
> general, require cross-feature order to be maintained.
>
> Granted, it doesn't seem to buy you anything in this case, since there's
> only one element inside the choice. But then, what's the purpose of the
> choice at all? Removing the choice would produce a simpler structure
> with just five features (when, instrumentIdentifier, source, other, id).
>
> Cheers,
> Dave
>
>
> david wrote:
>> Hi,
>>
>> This was on emft list, associated with Teneo. But since it is driven
>> by the eCore generated model I assume it would be better here. Here is
>> the discussion so far.
>>
>> The problem is that we end up with a "Feature group :
>> EFeatureMapEntry" when it looks to me like we do not need one.
>>
>> Maybe I have to write some XSLT to alter the XSD to produce a
>> construct that the ECore generator can work with?
>>
>> .....
>>
>> I think it is caused by the <xsd:choice minOccurs="0"
>> maxOccurs="unbounded"> choice. Can you try something like this:
>> <xsd:complexType name="CashDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> <xsd:element ref="gensec:instrumentIdentifier" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> </xsd:sequence>
>> <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> </xsd:complexType>
>> <xsd:element name="cashDomain" type="gensec:CashDomain" />
>>
>> btw, you can check if your change will result in a different mapping
>> by looking at the generated java code, it should not generate a group
>> member in CashDomain (at least not if you want 1:n).
>>
>>
>>
>> gr. Martin
>>
>> david wrote:
>> > Martin,
>> >
>> > I am still not understanding the reason behind the n:m association
>> generation when it appears to me to require 1:n.
>> >
>> > Say we have this
>> >
>> > <xsd:complexType name="CashDomain">
>> > <xsd:sequence>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> > <xsd:choice minOccurs="0" maxOccurs="unbounded">
>> > <xsd:element ref="gensec:instrumentIdentifier" />
>> > </xsd:choice>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> > </xsd:sequence>
>> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> > </xsd:complexType>
>> > <xsd:element name="cashDomain" type="gensec:CashDomain" />
>> >
>> >
>> > And the gensec:instrumentIdentifier looks like this
>> >
>> > <xsd:complexType name="InstrumentIdentifier">
>> > <xsd:sequence minOccurs="0" maxOccurs="1">
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> > <xsd:group minOccurs="0" maxOccurs="unbounded"
>> ref="gensec:InstrumentIdentifier.children" />
>> > <xsd:choice minOccurs="0" maxOccurs="1">
>> > <xsd:element ref="gensec:source" />
>> > </xsd:choice>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> > </xsd:sequence>
>> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> > </xsd:complexType>
>> > <xsd:element name="instrumentIdentifier"
>> type="gensec:InstrumentIdentifier" />
>> >
>> > This looks like to me there is a 1:n relationship between
>> cashDomain and instrumentIdentifier. But I end up with a n:m
>> supported through a table called cashdomain_group.
>> >
>> > What can I do to the XSD to force a 1:n association in the database
>> for these?
>> >
>> > David
Re: Getting n:m when I expect 1:n [message #615490 is a reply to message #112242] Tue, 12 February 2008 09:15 Go to previous message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

I agree entirely, the model is a standard ( mddl.org) that was designed
to be extensible and in fact therefore ignores a lot of real world
cardinality rules associated with the actual data. I am changing it to
reflect the real cardinality.

Thx.

David

Dave Steinberg wrote:
> Hi David,
>
> Martin is correct in that the EFeatureMap-typed group is created to
> represent the repeating model group. It is created whether the group is
> a sequence, choice, or all, since any of those constructs could, in
> general, require cross-feature order to be maintained.
>
> Granted, it doesn't seem to buy you anything in this case, since there's
> only one element inside the choice. But then, what's the purpose of the
> choice at all? Removing the choice would produce a simpler structure
> with just five features (when, instrumentIdentifier, source, other, id).
>
> Cheers,
> Dave
>
>
> david wrote:
>> Hi,
>>
>> This was on emft list, associated with Teneo. But since it is driven
>> by the eCore generated model I assume it would be better here. Here is
>> the discussion so far.
>>
>> The problem is that we end up with a "Feature group :
>> EFeatureMapEntry" when it looks to me like we do not need one.
>>
>> Maybe I have to write some XSLT to alter the XSD to produce a
>> construct that the ECore generator can work with?
>>
>> .....
>>
>> I think it is caused by the <xsd:choice minOccurs="0"
>> maxOccurs="unbounded"> choice. Can you try something like this:
>> <xsd:complexType name="CashDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> <xsd:element ref="gensec:instrumentIdentifier" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
>> <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> </xsd:sequence>
>> <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> </xsd:complexType>
>> <xsd:element name="cashDomain" type="gensec:CashDomain" />
>>
>> btw, you can check if your change will result in a different mapping
>> by looking at the generated java code, it should not generate a group
>> member in CashDomain (at least not if you want 1:n).
>>
>>
>>
>> gr. Martin
>>
>> david wrote:
>> > Martin,
>> >
>> > I am still not understanding the reason behind the n:m association
>> generation when it appears to me to require 1:n.
>> >
>> > Say we have this
>> >
>> > <xsd:complexType name="CashDomain">
>> > <xsd:sequence>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> > <xsd:choice minOccurs="0" maxOccurs="unbounded">
>> > <xsd:element ref="gensec:instrumentIdentifier" />
>> > </xsd:choice>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:source" />
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> > </xsd:sequence>
>> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> > </xsd:complexType>
>> > <xsd:element name="cashDomain" type="gensec:CashDomain" />
>> >
>> >
>> > And the gensec:instrumentIdentifier looks like this
>> >
>> > <xsd:complexType name="InstrumentIdentifier">
>> > <xsd:sequence minOccurs="0" maxOccurs="1">
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:when" />
>> > <xsd:group minOccurs="0" maxOccurs="unbounded"
>> ref="gensec:InstrumentIdentifier.children" />
>> > <xsd:choice minOccurs="0" maxOccurs="1">
>> > <xsd:element ref="gensec:source" />
>> > </xsd:choice>
>> > <xsd:element minOccurs="0" maxOccurs="1" ref="gensec:other" />
>> > </xsd:sequence>
>> > <xsd:attribute name="id" type="xsd:ID" use="optional" />
>> > </xsd:complexType>
>> > <xsd:element name="instrumentIdentifier"
>> type="gensec:InstrumentIdentifier" />
>> >
>> > This looks like to me there is a 1:n relationship between
>> cashDomain and instrumentIdentifier. But I end up with a n:m
>> supported through a table called cashdomain_group.
>> >
>> > What can I do to the XSD to force a 1:n association in the database
>> for these?
>> >
>> > David
Previous Topic:Re: Getting n:m when I expect 1:n
Next Topic:Table naming conventions
Goto Forum:
  


Current Time: Wed Jun 23 09:51:38 GMT 2021

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

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

Back to the top