| Hi Michael,
It might be good to put together the SQL definition as a first step to discuss the proposal.
Thanks,
Craig On Jul 27, 2005, at 8:55 AM, Craig Russell wrote: 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.
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 [EMAIL PROTECTED] Engineering GmbH Tel.: ++49/30/235 520 36 10783 Berlin - Germany -------------------------------------------------------------------
Craig Russell P.S. A good JDO? O, Gasp! |
smime.p7s