db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Date Mon, 05 Dec 2005 12:55:03 GMT
Hi Andy,

>>Inheritance mapping 2 fails. JPOX doesn't
>>support it, and the mapping isn't consistent. This needs a few
>>things: UNION join strategy plus generating a sequence used in
>>multiple tables. JDO-167
>>Inheritance 3 fails. Optimization of inheritance 1 where there is no
>>table for abstract classes. JPOX doesn't support it. AI Craig:
>>discuss this mapping with expert group. It might be an optional feature.
> To be specific, JPOX doesn't currently support a 1-N relation with the element 
> using subclass-table. This doesn't mean that work hasn't been done to take 
> the implementation of this so far, but the end result so far is that the 
> support is not complete. 
> One issue I would have is how a join-table relation like this should be 
> represented in the datastore (the join table structure). What I am planning 
> to do is handle it like how we handle collections of interfaces. With this 
> the join table has a FK column for each possible implementation. So in the 
> case of a 1-N relation with an element using subclass-table, and having 2 
> subclasses then the join table would be
> OWNER_ID  (FK back to owner table)
> SUBCLASS_1_ID   (FK to SUBCLASS_1 table)
> SUBCLASS_2_ID   (FK to SUBCLASS_2 table)
> ORDER_ID   (part of the PK)
> with the SUBCLASS_1_ID, SUBCLASS_2_ID being populated if the element is of 
> that type. I see nothing in the JDO2 spec to say that this has to be the way 
> that it is represented, so it becomes the choice of the JDO implementation. 
I think, the intent of your proposal is to store the runtime type of the 
relationship together with the foreign key value in the database. You 
would replace a foreign key by a set of foreign keys. The set size would 
equal the number of subclasses. This would also apply to 1-1, 1-N 
relationhips not being contained in a jointable, e.g. manager, right?

I think, there are several optional ways to compute the runtime type of 

1) FK per subclass (your proposal).
2) Discriminator per FK.
3) Union statement involving tables of all subclasses.

I think, options 1) and 2) require the ORM DTD to be extended: Regarding 
1), the column mapping of relationship fields must be capable to specify 
alternative FKs. Regarding 2), the column mapping of relationship fields 
must include a discriminator column.

Option 3) requires unique PK values for all instances in an inheritance 
hierarchy, e.g. Person, PartTimeEmployee, and FullTimeEmployee. An 
implementation-defined sequence may be used in the ORM for this purpose:

     <class name="Person" ...>
         <field name="personid" column="PERSONID" primary-key="true" 

     <class name="PartTimeEmployee" table="parttimeemployees">
         <field name="Person.personid" column="PERSONID" 
primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>

     <class name="FullTimeEmployee" table="fulltimeemployees">
         <field name="Person.personid" column="PERSONID" 
primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
     <sequence name="org.apache.jdo.tck.pc.PersonSequence" 

When we discussed this issue the last time, we decided to go for option 
3). This would be an optional feature that JDO implementations may 
support. For this reason, a new JDO option would be added to the spec. 
The TCK would check if the option is supported when mapping 2 is used.

Is this decision still valid?

> Do either of inheritance2, inheritance3 test this and what do they assume is 
> the join table structure ?

Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/

View raw message