Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Database ends up with group when it is 1:m not n:m associations
| |
| Re: Database ends up with group when it is 1:m not n:m associations [message #112105 is a reply to message #112006] |
Mon, 11 February 2008 10:54   |
 David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi,
I am not sure why the working group that developed this standard XSD
have a lot of the 1:n associations, also why they use 1:1 for many of
these associations too, I am trying to find out. I am also altering them
to be more straightforward associations instead of the unusual
constructs they have used.
Another thing I noticed is that even with
props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
I am getting e_version columns generated on some tables.
Regards,
David
Martin Taal wrote:
> Hi David,
> The group is created because of the <xsd:choice minOccurs="0"
> maxOccurs="unbounded">. Because of unbounded (actually anything above 1)
> it means that on the java side it is modeled with a list and in the
> database with a table.
>
> If I understand your correctly then the model could also be described as
> such:
>
> <xsd:complexType name="InstrumentDomain">
> <xsd:sequence>
> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
> <xsd:element ref="mddl:agencyRankings" minOccurs="0" maxOccurs="1"/>
> <xsd:element ref="mddl:agencyRatings" minOccurs="0" maxOccurs="1"/>
>
> the only difference is that the order of the agencyRankings and
> agencyRatings is not flexible (if they would occur at the same time).
>
> This simpler xsd would result in a database model without the group
> table. Also emf will generate a simpler class model.
>
> btw, for my curiosity why have the choice with minOccurs="1"
> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>
> gr. Martin
>
> david wrote:
>> Hi,
>>
>> The schema I am using has a particular approach to minimise the size
>> of XML messages.
>>
>> Here is a small excerpt
>>
>> <xsd:complexType name="InstrumentDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>> <xsd:choice minOccurs="1" maxOccurs="1">
>> <xsd:element ref="mddl:agencyRankings" />
>> </xsd:choice>
>> <xsd:choice minOccurs="1" maxOccurs="1">
>> <xsd:element ref="mddl:agencyRatings" />
>> </xsd:choice>
>> ....
>> etc.
>>
>> I end up with
>>
>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>> agencyratings id instrumentdomain_group group_agencyratings
>>
>> in the database generated.
>>
>> The real world model here is that instrumentDomain has a 1:1
>> relationship with agencyRankings and agencyRatings. Is the generation
>> of a group table and the inclusion of these entities due to the fact
>> they used a xsd:sequence with xsd:choice inside it? I assume the
>> maxOccurs="1" are not being taken into account.
>>
>> Is there a way of changing the generated output to accommodate these
>> maxOccur"1" within the xsd:choice? Or is the XSD model structure going
>> to force the creation of the n:m group?
>>
>> Thx,
>>
>> David
>>
>>
>>
>>
>
>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112148 is a reply to message #112105] |
Mon, 11 February 2008 12:00 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi David,
On which table/type are they still added? Then I can repair that.
gr. Martin
david wrote:
> Hi,
>
> I am not sure why the working group that developed this standard XSD
> have a lot of the 1:n associations, also why they use 1:1 for many of
> these associations too, I am trying to find out. I am also altering them
> to be more straightforward associations instead of the unusual
> constructs they have used.
>
> Another thing I noticed is that even with
>
> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>
> I am getting e_version columns generated on some tables.
>
> Regards,
>
> David
>
> Martin Taal wrote:
>> Hi David,
>> The group is created because of the <xsd:choice minOccurs="0"
>> maxOccurs="unbounded">. Because of unbounded (actually anything above
>> 1) it means that on the java side it is modeled with a list and in the
>> database with a table.
>>
>> If I understand your correctly then the model could also be described
>> as such:
>>
>> <xsd:complexType name="InstrumentDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>> maxOccurs="1"/>
>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>> maxOccurs="1"/>
>>
>> the only difference is that the order of the agencyRankings and
>> agencyRatings is not flexible (if they would occur at the same time).
>>
>> This simpler xsd would result in a database model without the group
>> table. Also emf will generate a simpler class model.
>>
>> btw, for my curiosity why have the choice with minOccurs="1"
>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> The schema I am using has a particular approach to minimise the size
>>> of XML messages.
>>>
>>> Here is a small excerpt
>>>
>>> <xsd:complexType name="InstrumentDomain">
>>> <xsd:sequence>
>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>> <xsd:element ref="mddl:agencyRankings" />
>>> </xsd:choice>
>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>> <xsd:element ref="mddl:agencyRatings" />
>>> </xsd:choice>
>>> ....
>>> etc.
>>>
>>> I end up with
>>>
>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>> agencyratings id instrumentdomain_group group_agencyratings
>>>
>>> in the database generated.
>>>
>>> The real world model here is that instrumentDomain has a 1:1
>>> relationship with agencyRankings and agencyRatings. Is the
>>> generation of a group table and the inclusion of these entities due
>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>> assume the maxOccurs="1" are not being taken into account.
>>>
>>> Is there a way of changing the generated output to accommodate these
>>> maxOccur"1" within the xsd:choice? Or is the XSD model structure
>>> going to force the creation of the n:m group?
>>>
>>> Thx,
>>>
>>> David
>>>
>>>
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112161 is a reply to message #112148] |
Mon, 11 February 2008 15:14 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Martin,
All *children named entities have the e_version.
David
Martin Taal wrote:
> Hi David,
> On which table/type are they still added? Then I can repair that.
>
> gr. Martin
>
> david wrote:
>> Hi,
>>
>> I am not sure why the working group that developed this standard XSD
>> have a lot of the 1:n associations, also why they use 1:1 for many of
>> these associations too, I am trying to find out. I am also altering
>> them to be more straightforward associations instead of the unusual
>> constructs they have used.
>>
>> Another thing I noticed is that even with
>>
>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>
>> I am getting e_version columns generated on some tables.
>>
>> Regards,
>>
>> David
>>
>> Martin Taal wrote:
>>> Hi David,
>>> The group is created because of the <xsd:choice minOccurs="0"
>>> maxOccurs="unbounded">. Because of unbounded (actually anything above
>>> 1) it means that on the java side it is modeled with a list and in
>>> the database with a table.
>>>
>>> If I understand your correctly then the model could also be described
>>> as such:
>>>
>>> <xsd:complexType name="InstrumentDomain">
>>> <xsd:sequence>
>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>> maxOccurs="1"/>
>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>> maxOccurs="1"/>
>>>
>>> the only difference is that the order of the agencyRankings and
>>> agencyRatings is not flexible (if they would occur at the same time).
>>>
>>> This simpler xsd would result in a database model without the group
>>> table. Also emf will generate a simpler class model.
>>>
>>> btw, for my curiosity why have the choice with minOccurs="1"
>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> The schema I am using has a particular approach to minimise the size
>>>> of XML messages.
>>>>
>>>> Here is a small excerpt
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>> <xsd:element ref="mddl:agencyRankings" />
>>>> </xsd:choice>
>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>> <xsd:element ref="mddl:agencyRatings" />
>>>> </xsd:choice>
>>>> ....
>>>> etc.
>>>>
>>>> I end up with
>>>>
>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>
>>>> in the database generated.
>>>>
>>>> The real world model here is that instrumentDomain has a 1:1
>>>> relationship with agencyRankings and agencyRatings. Is the
>>>> generation of a group table and the inclusion of these entities due
>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>> assume the maxOccurs="1" are not being taken into account.
>>>>
>>>> Is there a way of changing the generated output to accommodate these
>>>> maxOccur"1" within the xsd:choice? Or is the XSD model structure
>>>> going to force the creation of the n:m group?
>>>>
>>>> Thx,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112174 is a reply to message #112161] |
Mon, 11 February 2008 15:34 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Martin,
Also all *_group entities have a e_version column added.
David
david wrote:
> Martin,
>
> All *children named entities have the e_version.
>
> David
>
>
> Martin Taal wrote:
>> Hi David,
>> On which table/type are they still added? Then I can repair that.
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> I am not sure why the working group that developed this standard XSD
>>> have a lot of the 1:n associations, also why they use 1:1 for many of
>>> these associations too, I am trying to find out. I am also altering
>>> them to be more straightforward associations instead of the unusual
>>> constructs they have used.
>>>
>>> Another thing I noticed is that even with
>>>
>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>
>>> I am getting e_version columns generated on some tables.
>>>
>>> Regards,
>>>
>>> David
>>>
>>> Martin Taal wrote:
>>>> Hi David,
>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>> above 1) it means that on the java side it is modeled with a list
>>>> and in the database with a table.
>>>>
>>>> If I understand your correctly then the model could also be
>>>> described as such:
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>>
>>>> the only difference is that the order of the agencyRankings and
>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>
>>>> This simpler xsd would result in a database model without the group
>>>> table. Also emf will generate a simpler class model.
>>>>
>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>
>>>> gr. Martin
>>>>
>>>> david wrote:
>>>>> Hi,
>>>>>
>>>>> The schema I am using has a particular approach to minimise the
>>>>> size of XML messages.
>>>>>
>>>>> Here is a small excerpt
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>> </xsd:choice>
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>> </xsd:choice>
>>>>> ....
>>>>> etc.
>>>>>
>>>>> I end up with
>>>>>
>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>
>>>>> in the database generated.
>>>>>
>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>> generation of a group table and the inclusion of these entities due
>>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>>> assume the maxOccurs="1" are not being taken into account.
>>>>>
>>>>> Is there a way of changing the generated output to accommodate
>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>> structure going to force the creation of the n:m group?
>>>>>
>>>>> Thx,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112187 is a reply to message #112174] |
Mon, 11 February 2008 15:37 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi David,
Ok, I know where to look then. I'll solve this in the next build.
gr. Martin
david wrote:
> Martin,
>
> Also all *_group entities have a e_version column added.
>
> David
>
>
> david wrote:
>> Martin,
>>
>> All *children named entities have the e_version.
>>
>> David
>>
>>
>> Martin Taal wrote:
>>> Hi David,
>>> On which table/type are they still added? Then I can repair that.
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> I am not sure why the working group that developed this standard XSD
>>>> have a lot of the 1:n associations, also why they use 1:1 for many
>>>> of these associations too, I am trying to find out. I am also
>>>> altering them to be more straightforward associations instead of the
>>>> unusual constructs they have used.
>>>>
>>>> Another thing I noticed is that even with
>>>>
>>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>>
>>>> I am getting e_version columns generated on some tables.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Martin Taal wrote:
>>>>> Hi David,
>>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>>> above 1) it means that on the java side it is modeled with a list
>>>>> and in the database with a table.
>>>>>
>>>>> If I understand your correctly then the model could also be
>>>>> described as such:
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>>
>>>>> the only difference is that the order of the agencyRankings and
>>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>>
>>>>> This simpler xsd would result in a database model without the group
>>>>> table. Also emf will generate a simpler class model.
>>>>>
>>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> david wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The schema I am using has a particular approach to minimise the
>>>>>> size of XML messages.
>>>>>>
>>>>>> Here is a small excerpt
>>>>>>
>>>>>> <xsd:complexType name="InstrumentDomain">
>>>>>> <xsd:sequence>
>>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>>> </xsd:choice>
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>>> </xsd:choice>
>>>>>> ....
>>>>>> etc.
>>>>>>
>>>>>> I end up with
>>>>>>
>>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>>
>>>>>> in the database generated.
>>>>>>
>>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>>> generation of a group table and the inclusion of these entities
>>>>>> due to the fact they used a xsd:sequence with xsd:choice inside
>>>>>> it? I assume the maxOccurs="1" are not being taken into account.
>>>>>>
>>>>>> Is there a way of changing the generated output to accommodate
>>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>>> structure going to force the creation of the n:m group?
>>>>>>
>>>>>> Thx,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112199 is a reply to message #112161] |
Mon, 11 February 2008 15:44 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
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
david wrote:
> Martin,
>
> All *children named entities have the e_version.
>
> David
>
>
> Martin Taal wrote:
>> Hi David,
>> On which table/type are they still added? Then I can repair that.
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> I am not sure why the working group that developed this standard XSD
>>> have a lot of the 1:n associations, also why they use 1:1 for many of
>>> these associations too, I am trying to find out. I am also altering
>>> them to be more straightforward associations instead of the unusual
>>> constructs they have used.
>>>
>>> Another thing I noticed is that even with
>>>
>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>
>>> I am getting e_version columns generated on some tables.
>>>
>>> Regards,
>>>
>>> David
>>>
>>> Martin Taal wrote:
>>>> Hi David,
>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>> above 1) it means that on the java side it is modeled with a list
>>>> and in the database with a table.
>>>>
>>>> If I understand your correctly then the model could also be
>>>> described as such:
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>>
>>>> the only difference is that the order of the agencyRankings and
>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>
>>>> This simpler xsd would result in a database model without the group
>>>> table. Also emf will generate a simpler class model.
>>>>
>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>
>>>> gr. Martin
>>>>
>>>> david wrote:
>>>>> Hi,
>>>>>
>>>>> The schema I am using has a particular approach to minimise the
>>>>> size of XML messages.
>>>>>
>>>>> Here is a small excerpt
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>> </xsd:choice>
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>> </xsd:choice>
>>>>> ....
>>>>> etc.
>>>>>
>>>>> I end up with
>>>>>
>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>
>>>>> in the database generated.
>>>>>
>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>> generation of a group table and the inclusion of these entities due
>>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>>> assume the maxOccurs="1" are not being taken into account.
>>>>>
>>>>> Is there a way of changing the generated output to accommodate
>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>> structure going to force the creation of the n:m group?
>>>>>
>>>>> Thx,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #112212 is a reply to message #112199] |
Mon, 11 February 2008 16:27 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
David,
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
>
> david wrote:
>> Martin,
>>
>> All *children named entities have the e_version.
>>
>> David
>>
>>
>> Martin Taal wrote:
>>> Hi David,
>>> On which table/type are they still added? Then I can repair that.
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> I am not sure why the working group that developed this standard XSD
>>>> have a lot of the 1:n associations, also why they use 1:1 for many
>>>> of these associations too, I am trying to find out. I am also
>>>> altering them to be more straightforward associations instead of the
>>>> unusual constructs they have used.
>>>>
>>>> Another thing I noticed is that even with
>>>>
>>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>>
>>>> I am getting e_version columns generated on some tables.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Martin Taal wrote:
>>>>> Hi David,
>>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>>> above 1) it means that on the java side it is modeled with a list
>>>>> and in the database with a table.
>>>>>
>>>>> If I understand your correctly then the model could also be
>>>>> described as such:
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>>
>>>>> the only difference is that the order of the agencyRankings and
>>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>>
>>>>> This simpler xsd would result in a database model without the group
>>>>> table. Also emf will generate a simpler class model.
>>>>>
>>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> david wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The schema I am using has a particular approach to minimise the
>>>>>> size of XML messages.
>>>>>>
>>>>>> Here is a small excerpt
>>>>>>
>>>>>> <xsd:complexType name="InstrumentDomain">
>>>>>> <xsd:sequence>
>>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>>> </xsd:choice>
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>>> </xsd:choice>
>>>>>> ....
>>>>>> etc.
>>>>>>
>>>>>> I end up with
>>>>>>
>>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>>
>>>>>> in the database generated.
>>>>>>
>>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>>> generation of a group table and the inclusion of these entities
>>>>>> due to the fact they used a xsd:sequence with xsd:choice inside
>>>>>> it? I assume the maxOccurs="1" are not being taken into account.
>>>>>>
>>>>>> Is there a way of changing the generated output to accommodate
>>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>>> structure going to force the creation of the n:m group?
>>>>>>
>>>>>> Thx,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: Database ends up with group when it is 1:m not n:m associations [message #615478 is a reply to message #112006] |
Mon, 11 February 2008 10:54 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi,
I am not sure why the working group that developed this standard XSD
have a lot of the 1:n associations, also why they use 1:1 for many of
these associations too, I am trying to find out. I am also altering them
to be more straightforward associations instead of the unusual
constructs they have used.
Another thing I noticed is that even with
props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
I am getting e_version columns generated on some tables.
Regards,
David
Martin Taal wrote:
> Hi David,
> The group is created because of the <xsd:choice minOccurs="0"
> maxOccurs="unbounded">. Because of unbounded (actually anything above 1)
> it means that on the java side it is modeled with a list and in the
> database with a table.
>
> If I understand your correctly then the model could also be described as
> such:
>
> <xsd:complexType name="InstrumentDomain">
> <xsd:sequence>
> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
> <xsd:element ref="mddl:agencyRankings" minOccurs="0" maxOccurs="1"/>
> <xsd:element ref="mddl:agencyRatings" minOccurs="0" maxOccurs="1"/>
>
> the only difference is that the order of the agencyRankings and
> agencyRatings is not flexible (if they would occur at the same time).
>
> This simpler xsd would result in a database model without the group
> table. Also emf will generate a simpler class model.
>
> btw, for my curiosity why have the choice with minOccurs="1"
> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>
> gr. Martin
>
> david wrote:
>> Hi,
>>
>> The schema I am using has a particular approach to minimise the size
>> of XML messages.
>>
>> Here is a small excerpt
>>
>> <xsd:complexType name="InstrumentDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>> <xsd:choice minOccurs="1" maxOccurs="1">
>> <xsd:element ref="mddl:agencyRankings" />
>> </xsd:choice>
>> <xsd:choice minOccurs="1" maxOccurs="1">
>> <xsd:element ref="mddl:agencyRatings" />
>> </xsd:choice>
>> ....
>> etc.
>>
>> I end up with
>>
>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>> agencyratings id instrumentdomain_group group_agencyratings
>>
>> in the database generated.
>>
>> The real world model here is that instrumentDomain has a 1:1
>> relationship with agencyRankings and agencyRatings. Is the generation
>> of a group table and the inclusion of these entities due to the fact
>> they used a xsd:sequence with xsd:choice inside it? I assume the
>> maxOccurs="1" are not being taken into account.
>>
>> Is there a way of changing the generated output to accommodate these
>> maxOccur"1" within the xsd:choice? Or is the XSD model structure going
>> to force the creation of the n:m group?
>>
>> Thx,
>>
>> David
>>
>>
>>
>>
>
>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615482 is a reply to message #112105] |
Mon, 11 February 2008 12:00 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi David,
On which table/type are they still added? Then I can repair that.
gr. Martin
david wrote:
> Hi,
>
> I am not sure why the working group that developed this standard XSD
> have a lot of the 1:n associations, also why they use 1:1 for many of
> these associations too, I am trying to find out. I am also altering them
> to be more straightforward associations instead of the unusual
> constructs they have used.
>
> Another thing I noticed is that even with
>
> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>
> I am getting e_version columns generated on some tables.
>
> Regards,
>
> David
>
> Martin Taal wrote:
>> Hi David,
>> The group is created because of the <xsd:choice minOccurs="0"
>> maxOccurs="unbounded">. Because of unbounded (actually anything above
>> 1) it means that on the java side it is modeled with a list and in the
>> database with a table.
>>
>> If I understand your correctly then the model could also be described
>> as such:
>>
>> <xsd:complexType name="InstrumentDomain">
>> <xsd:sequence>
>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>> maxOccurs="1"/>
>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>> maxOccurs="1"/>
>>
>> the only difference is that the order of the agencyRankings and
>> agencyRatings is not flexible (if they would occur at the same time).
>>
>> This simpler xsd would result in a database model without the group
>> table. Also emf will generate a simpler class model.
>>
>> btw, for my curiosity why have the choice with minOccurs="1"
>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> The schema I am using has a particular approach to minimise the size
>>> of XML messages.
>>>
>>> Here is a small excerpt
>>>
>>> <xsd:complexType name="InstrumentDomain">
>>> <xsd:sequence>
>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>> <xsd:element ref="mddl:agencyRankings" />
>>> </xsd:choice>
>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>> <xsd:element ref="mddl:agencyRatings" />
>>> </xsd:choice>
>>> ....
>>> etc.
>>>
>>> I end up with
>>>
>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>> agencyratings id instrumentdomain_group group_agencyratings
>>>
>>> in the database generated.
>>>
>>> The real world model here is that instrumentDomain has a 1:1
>>> relationship with agencyRankings and agencyRatings. Is the
>>> generation of a group table and the inclusion of these entities due
>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>> assume the maxOccurs="1" are not being taken into account.
>>>
>>> Is there a way of changing the generated output to accommodate these
>>> maxOccur"1" within the xsd:choice? Or is the XSD model structure
>>> going to force the creation of the n:m group?
>>>
>>> Thx,
>>>
>>> David
>>>
>>>
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615483 is a reply to message #112148] |
Mon, 11 February 2008 15:14 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Martin,
All *children named entities have the e_version.
David
Martin Taal wrote:
> Hi David,
> On which table/type are they still added? Then I can repair that.
>
> gr. Martin
>
> david wrote:
>> Hi,
>>
>> I am not sure why the working group that developed this standard XSD
>> have a lot of the 1:n associations, also why they use 1:1 for many of
>> these associations too, I am trying to find out. I am also altering
>> them to be more straightforward associations instead of the unusual
>> constructs they have used.
>>
>> Another thing I noticed is that even with
>>
>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>
>> I am getting e_version columns generated on some tables.
>>
>> Regards,
>>
>> David
>>
>> Martin Taal wrote:
>>> Hi David,
>>> The group is created because of the <xsd:choice minOccurs="0"
>>> maxOccurs="unbounded">. Because of unbounded (actually anything above
>>> 1) it means that on the java side it is modeled with a list and in
>>> the database with a table.
>>>
>>> If I understand your correctly then the model could also be described
>>> as such:
>>>
>>> <xsd:complexType name="InstrumentDomain">
>>> <xsd:sequence>
>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>> maxOccurs="1"/>
>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>> maxOccurs="1"/>
>>>
>>> the only difference is that the order of the agencyRankings and
>>> agencyRatings is not flexible (if they would occur at the same time).
>>>
>>> This simpler xsd would result in a database model without the group
>>> table. Also emf will generate a simpler class model.
>>>
>>> btw, for my curiosity why have the choice with minOccurs="1"
>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> The schema I am using has a particular approach to minimise the size
>>>> of XML messages.
>>>>
>>>> Here is a small excerpt
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>> <xsd:element ref="mddl:agencyRankings" />
>>>> </xsd:choice>
>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>> <xsd:element ref="mddl:agencyRatings" />
>>>> </xsd:choice>
>>>> ....
>>>> etc.
>>>>
>>>> I end up with
>>>>
>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>
>>>> in the database generated.
>>>>
>>>> The real world model here is that instrumentDomain has a 1:1
>>>> relationship with agencyRankings and agencyRatings. Is the
>>>> generation of a group table and the inclusion of these entities due
>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>> assume the maxOccurs="1" are not being taken into account.
>>>>
>>>> Is there a way of changing the generated output to accommodate these
>>>> maxOccur"1" within the xsd:choice? Or is the XSD model structure
>>>> going to force the creation of the n:m group?
>>>>
>>>> Thx,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615484 is a reply to message #112161] |
Mon, 11 February 2008 15:34 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Martin,
Also all *_group entities have a e_version column added.
David
david wrote:
> Martin,
>
> All *children named entities have the e_version.
>
> David
>
>
> Martin Taal wrote:
>> Hi David,
>> On which table/type are they still added? Then I can repair that.
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> I am not sure why the working group that developed this standard XSD
>>> have a lot of the 1:n associations, also why they use 1:1 for many of
>>> these associations too, I am trying to find out. I am also altering
>>> them to be more straightforward associations instead of the unusual
>>> constructs they have used.
>>>
>>> Another thing I noticed is that even with
>>>
>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>
>>> I am getting e_version columns generated on some tables.
>>>
>>> Regards,
>>>
>>> David
>>>
>>> Martin Taal wrote:
>>>> Hi David,
>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>> above 1) it means that on the java side it is modeled with a list
>>>> and in the database with a table.
>>>>
>>>> If I understand your correctly then the model could also be
>>>> described as such:
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>>
>>>> the only difference is that the order of the agencyRankings and
>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>
>>>> This simpler xsd would result in a database model without the group
>>>> table. Also emf will generate a simpler class model.
>>>>
>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>
>>>> gr. Martin
>>>>
>>>> david wrote:
>>>>> Hi,
>>>>>
>>>>> The schema I am using has a particular approach to minimise the
>>>>> size of XML messages.
>>>>>
>>>>> Here is a small excerpt
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>> </xsd:choice>
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>> </xsd:choice>
>>>>> ....
>>>>> etc.
>>>>>
>>>>> I end up with
>>>>>
>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>
>>>>> in the database generated.
>>>>>
>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>> generation of a group table and the inclusion of these entities due
>>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>>> assume the maxOccurs="1" are not being taken into account.
>>>>>
>>>>> Is there a way of changing the generated output to accommodate
>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>> structure going to force the creation of the n:m group?
>>>>>
>>>>> Thx,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615485 is a reply to message #112174] |
Mon, 11 February 2008 15:37 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi David,
Ok, I know where to look then. I'll solve this in the next build.
gr. Martin
david wrote:
> Martin,
>
> Also all *_group entities have a e_version column added.
>
> David
>
>
> david wrote:
>> Martin,
>>
>> All *children named entities have the e_version.
>>
>> David
>>
>>
>> Martin Taal wrote:
>>> Hi David,
>>> On which table/type are they still added? Then I can repair that.
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> I am not sure why the working group that developed this standard XSD
>>>> have a lot of the 1:n associations, also why they use 1:1 for many
>>>> of these associations too, I am trying to find out. I am also
>>>> altering them to be more straightforward associations instead of the
>>>> unusual constructs they have used.
>>>>
>>>> Another thing I noticed is that even with
>>>>
>>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>>
>>>> I am getting e_version columns generated on some tables.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Martin Taal wrote:
>>>>> Hi David,
>>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>>> above 1) it means that on the java side it is modeled with a list
>>>>> and in the database with a table.
>>>>>
>>>>> If I understand your correctly then the model could also be
>>>>> described as such:
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>>
>>>>> the only difference is that the order of the agencyRankings and
>>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>>
>>>>> This simpler xsd would result in a database model without the group
>>>>> table. Also emf will generate a simpler class model.
>>>>>
>>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> david wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The schema I am using has a particular approach to minimise the
>>>>>> size of XML messages.
>>>>>>
>>>>>> Here is a small excerpt
>>>>>>
>>>>>> <xsd:complexType name="InstrumentDomain">
>>>>>> <xsd:sequence>
>>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>>> </xsd:choice>
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>>> </xsd:choice>
>>>>>> ....
>>>>>> etc.
>>>>>>
>>>>>> I end up with
>>>>>>
>>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>>
>>>>>> in the database generated.
>>>>>>
>>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>>> generation of a group table and the inclusion of these entities
>>>>>> due to the fact they used a xsd:sequence with xsd:choice inside
>>>>>> it? I assume the maxOccurs="1" are not being taken into account.
>>>>>>
>>>>>> Is there a way of changing the generated output to accommodate
>>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>>> structure going to force the creation of the n:m group?
>>>>>>
>>>>>> Thx,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615486 is a reply to message #112161] |
Mon, 11 February 2008 15:44 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
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
david wrote:
> Martin,
>
> All *children named entities have the e_version.
>
> David
>
>
> Martin Taal wrote:
>> Hi David,
>> On which table/type are they still added? Then I can repair that.
>>
>> gr. Martin
>>
>> david wrote:
>>> Hi,
>>>
>>> I am not sure why the working group that developed this standard XSD
>>> have a lot of the 1:n associations, also why they use 1:1 for many of
>>> these associations too, I am trying to find out. I am also altering
>>> them to be more straightforward associations instead of the unusual
>>> constructs they have used.
>>>
>>> Another thing I noticed is that even with
>>>
>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>
>>> I am getting e_version columns generated on some tables.
>>>
>>> Regards,
>>>
>>> David
>>>
>>> Martin Taal wrote:
>>>> Hi David,
>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>> above 1) it means that on the java side it is modeled with a list
>>>> and in the database with a table.
>>>>
>>>> If I understand your correctly then the model could also be
>>>> described as such:
>>>>
>>>> <xsd:complexType name="InstrumentDomain">
>>>> <xsd:sequence>
>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>> maxOccurs="1"/>
>>>>
>>>> the only difference is that the order of the agencyRankings and
>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>
>>>> This simpler xsd would result in a database model without the group
>>>> table. Also emf will generate a simpler class model.
>>>>
>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>
>>>> gr. Martin
>>>>
>>>> david wrote:
>>>>> Hi,
>>>>>
>>>>> The schema I am using has a particular approach to minimise the
>>>>> size of XML messages.
>>>>>
>>>>> Here is a small excerpt
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>> </xsd:choice>
>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>> </xsd:choice>
>>>>> ....
>>>>> etc.
>>>>>
>>>>> I end up with
>>>>>
>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>
>>>>> in the database generated.
>>>>>
>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>> generation of a group table and the inclusion of these entities due
>>>>> to the fact they used a xsd:sequence with xsd:choice inside it? I
>>>>> assume the maxOccurs="1" are not being taken into account.
>>>>>
>>>>> Is there a way of changing the generated output to accommodate
>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>> structure going to force the creation of the n:m group?
>>>>>
>>>>> Thx,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Database ends up with group when it is 1:m not n:m associations [message #615487 is a reply to message #112199] |
Mon, 11 February 2008 16:27 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
David,
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
>
> david wrote:
>> Martin,
>>
>> All *children named entities have the e_version.
>>
>> David
>>
>>
>> Martin Taal wrote:
>>> Hi David,
>>> On which table/type are they still added? Then I can repair that.
>>>
>>> gr. Martin
>>>
>>> david wrote:
>>>> Hi,
>>>>
>>>> I am not sure why the working group that developed this standard XSD
>>>> have a lot of the 1:n associations, also why they use 1:1 for many
>>>> of these associations too, I am trying to find out. I am also
>>>> altering them to be more straightforward associations instead of the
>>>> unusual constructs they have used.
>>>>
>>>> Another thing I noticed is that even with
>>>>
>>>> props.setProperty(PersistenceOptions.ALWAYS_VERSION, "false");
>>>>
>>>> I am getting e_version columns generated on some tables.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Martin Taal wrote:
>>>>> Hi David,
>>>>> The group is created because of the <xsd:choice minOccurs="0"
>>>>> maxOccurs="unbounded">. Because of unbounded (actually anything
>>>>> above 1) it means that on the java side it is modeled with a list
>>>>> and in the database with a table.
>>>>>
>>>>> If I understand your correctly then the model could also be
>>>>> described as such:
>>>>>
>>>>> <xsd:complexType name="InstrumentDomain">
>>>>> <xsd:sequence>
>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>> <xsd:element ref="mddl:agencyRankings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>> <xsd:element ref="mddl:agencyRatings" minOccurs="0"
>>>>> maxOccurs="1"/>
>>>>>
>>>>> the only difference is that the order of the agencyRankings and
>>>>> agencyRatings is not flexible (if they would occur at the same time).
>>>>>
>>>>> This simpler xsd would result in a database model without the group
>>>>> table. Also emf will generate a simpler class model.
>>>>>
>>>>> btw, for my curiosity why have the choice with minOccurs="1"
>>>>> maxOccurs="1" around the agencyRankings and agencyRatings elements?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> david wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The schema I am using has a particular approach to minimise the
>>>>>> size of XML messages.
>>>>>>
>>>>>> Here is a small excerpt
>>>>>>
>>>>>> <xsd:complexType name="InstrumentDomain">
>>>>>> <xsd:sequence>
>>>>>> <xsd:element minOccurs="0" maxOccurs="1" ref="mddl:when" />
>>>>>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRankings" />
>>>>>> </xsd:choice>
>>>>>> <xsd:choice minOccurs="1" maxOccurs="1">
>>>>>> <xsd:element ref="mddl:agencyRatings" />
>>>>>> </xsd:choice>
>>>>>> ....
>>>>>> etc.
>>>>>>
>>>>>> I end up with
>>>>>>
>>>>>> PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME
>>>>>> agencyratings id instrumentdomain_group group_agencyratings
>>>>>>
>>>>>> in the database generated.
>>>>>>
>>>>>> The real world model here is that instrumentDomain has a 1:1
>>>>>> relationship with agencyRankings and agencyRatings. Is the
>>>>>> generation of a group table and the inclusion of these entities
>>>>>> due to the fact they used a xsd:sequence with xsd:choice inside
>>>>>> it? I assume the maxOccurs="1" are not being taken into account.
>>>>>>
>>>>>> Is there a way of changing the generated output to accommodate
>>>>>> these maxOccur"1" within the xsd:choice? Or is the XSD model
>>>>>> structure going to force the creation of the n:m group?
>>>>>>
>>>>>> Thx,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
Goto Forum:
Current Time: Fri Apr 19 05:37:02 GMT 2024
Powered by FUDForum. Page generated in 0.03402 seconds |
] 
Search
Help
Register
Login
Home
