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: Questions concerning inheritance mappings
Date Wed, 27 Jul 2005 17:05:44 GMT
Hi Craig,

comments inline:

> Hi,
> 
> I'd like to get some feedback on this proposal from our JPOX team.
> 
> On Jul 27, 2005, at 7:43 AM, Michael Watzek wrote:
> 
>> Hi Craig,
>>
>> I like to confirm the the inheritance mappings, you proposed in TCK 
>> t-conference, Jul 8. This is an excerpt from the minutes:
>>
>> "
>> ...
>> Craig proposed to introduce 5 different inheritance mappings:
>> 1- one table for all classes in the inheritance hierarchy. The 
>> least-derived class specifies inheritance strategy "new-table"; all 
>> others "superclass-table".
>> 2- Separate table for each class in the inheritance strategy. Each 
>> table contains columns for the declared fields. Each class specifies 
>> inheritance strategy "new-table".
> 
> 
> Subclass tables are joined to their superclass tables via foreign key 
> from subclass primary key to superclass primary key.
> 
>> 3- Separate table for each class in the inheritance strategy. Each 
>> table contains column for all fields. Each class specifies inheritance 
>> strategy "new-table".
> 
> 
> Each derived class overrides fields from the superclass and maps them to 
> its own table.
> 
>> 4- Person has inheritance strategy "new-table". Employee has 
>> inheritance strategy "subclass". PartTimeEmployee has inheritance 
>> strategy "new-table".
> 
> 
> I think what we want here is only the most-derived classes are 
> instantiated and have new-table. All other tables are subclass-table. 
> This would mean that there are no instances of Person, Employee, or 
> Insurance in the test data.
> 
>> 5- Person has inheritance strategy "new-table". Employee has 
>> inheritance strategy "new-table". PartTimeEmployee has inheritance 
>> strategy "super-class".
>> ...
>> "
>>
>> Question concerning the first mapping:
>> Does it make sense to have the same table for all classes where each 
>> class specifies inheritance strategy "new-table"? Should the mapping 
>> rather specify "new-table" for the base class and "superclass-table" 
>> for all subclasses? This mapping is covered by "mapping 0" in the 
>> current build process.
> 
> 
> Yes, the least-derived classes have new-table; all others have 
> superclass-table, as in the current build.
> 
>>
>> Question concerning the third mapping:
>> In the XML testdata, there are mentors which are parttime employees 
>> and mentors which are fulltime employees. In particular, there are 
>> fulltime employees having parttime employees as mentors and other 
>> fulltime employees having fulltime employees as mentors. I'm not sure 
>> how this can be mapped if there are separate tables for fulltime 
>> employees and for parttime employees. Note, that a single column can 
>> only reference a single table, e.g. column FULLTIMEEMPLOYEES.MENTOR 
>> can not reference table FULLTIMEEMPLOYEE and table PARTTIMEEMPLOYEE. 
>> Even, if you drop the foreign key in the schema, the JDO runtime would 
>> not be able to figure out the correct instantiation type at navigation 
>> time. The same problem shows up for proteges.
>> A possible solution might be to define that fulltime employees can 
>> only have fulltime employees as mentors, relatively proteges. The same 
>> rule could be applied on parttime employees. As a consequence, we 
>> would have to adapt the XML testdata.
> 
> 
> How about only fulltime employees can be mentors? The foreign keys in 
> both full time and part time could refer to the fulltime employee table.
Ok, that's fine. I suggest to apply the same rule for other fields 
having the same problem:

- only fulltime employees can be managers.
- only fulltime employees can be hradvisors.
- only fulltime employees can have an insurance.

For project members, project reviewers, and phone numbers, we have 
separate tables in the schema. I suggest, to introduce two tables for 
each of them: One table for fulltime employees, the other table for 
parttime employees.

As a drawback, the JDO runtime must union those tables, e.g. figuring 
out members of projects, which might consist of fulltime employees and 
of parttime employees both. Is that a reasonable requirement?

If not, then projects would consist either of fulltime employees or of 
partime employees, but not of both in the same project.

Regards,
Michael
> 
> Yes, it would appear the test data would have to be adapted, but this 
> can be done to apply to all mappings. 
> 
>>
>> Question concerning the fourth mapping:
>> The same problem as described in the third mapping.
>>
>> Question concerning the fifth mapping:
>> I assume that FullTimeEmployee has inheritance strategy "super-class", 
>> right?
> 
> 
> Right.
> 
> Craig
> 
>>
>> Regards,
>> Michael
>> -- 
>> -------------------------------------------------------------------
>> 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/
>> -------------------------------------------------------------------
>>
> 
> Craig Russell
> 
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 
> 408 276-5638 mailto:Craig.Russell@sun.com
> 
> P.S. A good JDO? O, Gasp!
> 
> 


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