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, 17 Oct 2005 07:23:59 GMT
Hi Andy,

anything new on this topic?

Regards,
Michael

> 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                  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/
-------------------------------------------------------------------

Mime
View raw message