db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Inheritance proposal
Date Tue, 09 Aug 2005 16:55:09 GMT
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.
>
>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"/>
></class>
>which would mean that table TB will carry the value for that field (rather 
>than the column in table TA).
>
>
>
>
>  
>


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


Mime
View raw message