db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Date Mon, 05 Dec 2005 17:34:26 GMT
Hi Michael,

Thanks for your analysis. More comments below.

On Dec 5, 2005, at 4:55 AM, Michael Watzek wrote:

> 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.

It is true that there is nothing in the spec regarding how these two  
kinds of mappings are implemented. In the joined subclass it's clear  
that a foreign key might be used, but in the two failing cases here,  
there is no foreign key possible since the subclasses are mapped to  
independent tables (there is no common relationship among the tables,  
even though the key values are unique).

So I'm thinking that even if we do have an optional feature to  
support this kind of mapping, there is not a standard mapping that  
will be required. Your idea of having a different FK for each  
possible subclass is interesting. But I think that a different  
reasonable mapping would have one column that has no FK constraint at  
all but matches the primary key value of two different subclass tables.

> I think, the intent of your [Andy's] 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 relationships:
> 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.

We decided that discriminator columns for field mappings was not so  
important for embedded classes, and it seems that this is a similar  
case. I agree that extra ORM metadata would be needed to cater for 1)  
and 2).
> 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:

I don't think it's necessarily an application-defined sequence. It  
could be any named sequence.
>     ...
>     <class name="Person" ...>
>         ...
>         <field name="personid" column="PERSONID" primary-key="true"  
> sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>         ...
>     </class>
>     <class name="PartTimeEmployee" table="parttimeemployees">
>         ...
>         <field name="Person.personid" column="PERSONID" primary- 
> key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>         ...
>     </class>
>     <class name="FullTimeEmployee" table="fulltimeemployees">
>         ...
>         <field name="Person.personid" column="PERSONID" primary- 
> key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>         ...
>     </class>
>     ...
>     <sequence name="org.apache.jdo.tck.pc.PersonSequence"  
> strategy="nontransactional"/>
>     ...
> 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?

It still gets my vote. The metadata as you've described it makes  
sense for this strategy.

> Regards,
> Michael
>> 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/
> -------------------------------------------------------------------

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message