db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Questions concerning inheritance mappings
Date Wed, 27 Jul 2005 17:40:16 GMT
Hi,

On Jul 27, 2005, at 10:05 AM, Michael Watzek wrote:

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

Ok.

> - only fulltime employees can be hradvisors.

Ok.

> - only fulltime employees can have an insurance.

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

For phone numbers, this is fine.

I don't think this is practical for projects. For the reviewers field  
in project, you would have to map this field to two tables, which  
isn't possible. For this mapping, I think we need a different data  
file in which only fulltime employees are assigned to projects.

We should realize that this is a bit of an odd mapping that doesn't  
really meet the current data requirements, so we by necessity need  
different data.

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

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!


Mime
View raw message