Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Database ends up with group when it is 1:m not n:m associations
Database ends up with group when it is 1:m not n:m associations [message #111921] Fri, 08 February 2008 17:56 Go to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
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 #112006 is a reply to message #111921] Fri, 08 February 2008 19:31 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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 #112105 is a reply to message #112006] Mon, 11 February 2008 10:54 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
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 Go to previous message
Martin Taal is currently offline Martin TaalFriend
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 #615472 is a reply to message #111921] Fri, 08 February 2008 19:31 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
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 Go to previous message
David Wynter is currently offline David WynterFriend
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 Go to previous message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous message
David Wynter is currently offline David WynterFriend
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 Go to previous message
David Wynter is currently offline David WynterFriend
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 Go to previous message
Martin Taal is currently offline Martin TaalFriend
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 Go to previous message
David Wynter is currently offline David WynterFriend
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 Go to previous message
Martin Taal is currently offline Martin TaalFriend
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
Previous Topic:ECF and CDO technologies.
Next Topic:Obtaing Value
Goto Forum:
  


Current Time: Mon Jun 14 05:40:39 GMT 2021

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

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

Back to the top