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 Tue, 06 Dec 2005 15:45:31 GMT
Hi Craig,

> 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.
I'll prepare a patch, that adapts the ORM for mapping 2 as described 
above and that checks for the new option when mapping 2 is executed. For 
now, I'll assume the option name to be "javax.jdo.option.UnionJoin".

Regards,
Michael
> 
> Craig
> 
>>
>> 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!
> 
> 


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

Mime
View raw message