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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
