db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Inheritance test schema 2
Date Mon, 10 Oct 2005 14:57:37 GMT
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?


> 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                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/

View raw message