|
Home > Archive > Apache JDO Project > July 2005 > Questions concerning inheritance mappings
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Questions concerning inheritance mappings
|
|
| Michael Watzek 2005-07-27, 5:45 pm |
| 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 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 2005-07-27, 5:45 pm |
| | |
| Craig Russell 2005-07-27, 5:45 pm |
| | |
| Michael Watzek 2005-07-27, 5:45 pm |
| 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:
>
>
>
> Subclass tables are joined to their superclass tables via foreign key
> from subclass primary key to superclass primary key.
>
>
>
> Each derived class overrides fields from the superclass and maps them to
> its own 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.
>
>
>
> Yes, the least-derived classes have new-table; all others have
> superclass-table, as in the current build.
>
>
>
> 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.
>
>
>
> Right.
>
> Craig
>
>
> 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/
-------------------------------------------------------------------
| |
| erik@jpox.org 2005-07-27, 5:45 pm |
| Hi,
I'm not sure what you want Craig, but I can tell that all these 5 items should
work with JPOX
Regards,
Erik Bengtson
Quoting Craig Russell <Craig.Russell@Sun.COM>:
> 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:
>
>
> Subclass tables are joined to their superclass tables via foreign key
> from subclass primary key to superclass primary key.
>
>
> Each derived class overrides fields from the superclass and maps them
> to its own 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.
>
>
> Yes, the least-derived classes have new-table; all others have
> superclass-table, as in the current build.
>
> 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.
>
> Right.
>
> Craig
>
> 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!
>
>
| |
| Craig Russell 2005-07-27, 5:45 pm |
| |
|
|
|
|