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.
I think, the intent of your 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.
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:
...
<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?
Regards,
Michael
Do either of inheritance2, inheritance3 test this and what do they assume is
the join table structure ?
--
-------------------------------------------------------------------
Michael Watzek [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
