You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Watzek <mw...@spree.de> on 2005/07/27 16:43:39 UTC
Questions concerning inheritance mappings
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/
-------------------------------------------------------------------
Re: Questions concerning inheritance mappings
Posted by er...@jpox.org.
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 <Cr...@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:
>
> > 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 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!
>
>
Re: Questions concerning inheritance mappings
Posted by Craig Russell <Cr...@Sun.COM>.
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 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!
>
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!
Re: Questions concerning inheritance mappings
Posted by Craig Russell <Cr...@Sun.COM>.
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!
Re: Questions concerning inheritance mappings
Posted by Michael Watzek <mw...@spree.de>.
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 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/
-------------------------------------------------------------------
Re: Questions concerning inheritance mappings
Posted by Craig Russell <Cr...@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:
> 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 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!