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 [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/
-------------------------------------------------------------------
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
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/
-------------------------------------------------------------------
