db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Inheritance proposal
Date Wed, 10 Aug 2005 21:49:18 GMT
Hi Andy,

On Aug 9, 2005, at 9:55 AM, Michael Bouschen wrote:

> Hi Andy,
>
> thanks for the info! You are right, I forgot that I have the add  
> <field> elements for the inherited fields.
>
> Regards Michael
>
>
>>> Suppose there are two non-abstract persistence-capable classes A  
>>> and B.
>>> Class B extends A. Both explicitly define the inheritance strategy
>>> new-table. Class A maps to table TA and B maps to table TB. Then  
>>> there
>>> are still two scenarios possible, depending on where to store the
>>> inherited fields of B instances:
>>> (1) In table TA. Then we need a <join> element, since a class B  
>>> instance
>>> is represented by a row in table TA and a row in table TB.
>>> (2) In table TB. No <join> element is needed since TB includes  
>>> columns
>>> for the inherited fields. So TA only has rows for class A  
>>> instances, not
>>> for B instances.
>>>
>>>
>>
>> Hi Michael,
>>
>> that's not our interpretation of the spec :-)
>>
>> In your example if both classes have "new-table" then we have the  
>> fields specified in class A persisted into table TA, and the  
>> fields specified in class B persisted into table TB - so option 1  
>> (ONLY), and we do not need any <join> unless wanting to override  
>> the join column names (pk columns). An instance of B will have a  
>> row in TA, and an associated row in TB. An instance of A will have  
>> a row in TA only.

So to retrieve values for an instance of B, you need to select from  
both TA and TB. The reason many of us think of this as a join is that  
in order to do one SQL SELECT statement, an implementation will  
naturally do:

SELECT ta.name, ta.addr, tb.empid, tb.salary FROM TA ta, TB tb WHERE  
tb.pk = ta.pk AND tb.pk = ?

But you are right; the join doesn't need to be explicitly defined in  
the .orm, and there doesn't need to be a foreign key relationship in  
the database. But it does help to have the foreign key relationship  
to guarantee referential integrity.
>>
>> The only difference we see from option 1 is where the user decides  
>> to override the <field> specifications for a field of A, in class B
>> e.g <class name="B">
>>    <field name="A.field1"/>

Of course, you need to specify the <column name="FIELD1"/> because  
there are no defaults for column names...

>> </class>
>> which would mean that table TB will carry the value for that field  
>> (rather than the column in table TA).

This is my understanding as well for option 2 mapping. All of the  
inherited fields that come from A are mapped explicitly in B's orm.

Craig

>>
>>
>>
>>
>>
>>
>
>
> -- 
> Michael Bouschen        Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de    http://www.tech.spree.de/
> Tel.:++49/30/235 520-33        Buelowstr. 66
> Fax.:++49/30/2175 2012        D-10783 Berlin
>
>

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!


Mime
View raw message