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 table for all classes in the inheritance hierarchy. Each class
specifies inheritance strategy "new-table".
- Separate table for each class in the inheritance strategy. Each table
contains columns for the declared fields. Each class specifies
inheritance strategy "new-table".
- Separate table for each class in the inheritance strategy. Each table
contains column for all fields. Each class specifies inheritance
strategy "new-table".
- Person has inheritance strategy "new-table". Employee has inheritance
strategy "subclass". PartTimeEmployee has inheritance strategy "new-table".
- 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.
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.
Question concerning the forth 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?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
