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  |
 David Steinberg
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  |
David Wynter
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 |
David Wynter
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
|
|
|
Goto Forum:
Current Time: Fri Apr 26 23:57:10 GMT 2024
Powered by FUDForum. Page generated in 0.23113 seconds |
] 
Search
Help
Register
Login
Home
