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 [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/
-------------------------------------------------------------------
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
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/
-------------------------------------------------------------------
