Hi Andy,
I like to summarize the intent of inheritance mapping 2 and inheritance
mapping 3:
The intent of mapping 2 is to guarantee fast object access wrt inserts,
updates, deletes, and single selects (e.g. getObjectById). For this
reason, mapping 2 does not require discriminator columns in where
clauses as mapping 0 does. Moreover, no inheritance joins are required
as in mapping 1. Instead, each table contains columns for declared and
inherited fields.
The intent of mapping 3 is to optimize mapping 1 wrt abstract classes.
The differences between these mappings are that abstract classes are
mapped to subclass tables in mapping 3. Inheritance joins are introduced
from FullTimeEmployee to Person and from PartTimeEmployee to Person. Due
to the existence of inheritance joins, mapping 3 guarantees unique PK
values in the inheritance hierarchy.
The drawback of mapping 2 is that it does not guarantee unique PKs
values in the inheritance hierarchy. I'm not sure if identity strategy
"increment" solves this issue, because there are 3 tables involved
(persons, fulltimeemployees, parttimeemployees) which have to have
unique PK values. Note, that there are no inheritance joins between
these tables in mapping 2.
That's why Craig proposed an implementation-defined sequence for this
mapping. This sequence would be used by key generation for all involved
tables (persons, fulltimeemployees, parttimeemployees). Moreover, Craig
proposed a flag indicating if an implementation supports such a feature.
The TCK would skip mapping 2 for implementation not supporting that feature.
The current ORM does not support such sequences. The sequence attribute
of element <datastore-identity> is reserved for database sequences. I
think, if we include the concept of a named sequence class generating
unique values for a set of tables, then implementations are able to
handle relationship navigation in mapping 2.
What do you think?
Regards,
Michael
Hi Michael,
Craig proposed to drop the identity types on the PK columns of tables
persons, fulltimeemployees, and parttimeemployees. Instead, an
implementation-defined sequence should be used to generate unique PK
values for the three tables.
OK. As I mentioned in the previous post, the only ones that will cause issues
are the identity column specifications for "fulltimeemployees" and
"parttimeemployees". If you want to change all of the person inheritance tree
tables to use, for example, "increment" identity strategy then fine.
My understanding is that we do not introduce FKs from parttimeemployees
to persons and from fulltimeemployees to persons. Also, we do not
introduce inheritance <join> elements in the ORM for FullTimeEmployee
and PartTimeEmployee.
Does JPOX support such a mapping?
JPOX supports "subclass-table" inheritance on its own.
JPOX (as of yesterday) supports "subclass-table" inheritance combined with 1-N
relationships when there is at most 1 subclass of the collection element
class that has a table.
Your example is for a 1-N relation with the N side using "subclass-table" and
there being *more than 1* subclass (PartTimeEmployee, FullTimeEmployee). No,
JPOX does not currently support that. Sadly "inheritance2" and "inheritance3"
are both testing this situation.
There are actually good reasons why this situation ("subclass-table" with
relationships) in general is not currently supported, not because we're lazy
and can't be bothered to implement it :-)
1. it usually results in a schema that cannot have adequate FK constraints
imposed to guarantee referential integrity in the DB. In designing any system
I would avoid this combination because of just this reason.
2. it introduces significant added complexity to the retrieval of objects,
since there is no single base table to join to to find the object in the
collection
That doesn't mean that we don't want to support it or that we won't support
it, but it's all down to prioritisation of issues and for the reasons above
this has always in the past been a low priority one for us. For reference see
these 2 JPOX JIRA issues
http://www.jpox.org/servlet/jira/browse/CORE-2446
http://www.jpox.org/servlet/jira/browse/CORE-2466
--
-------------------------------------------------------------------
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/
-------------------------------------------------------------------
