db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Inheritance test schema 2
Date Thu, 29 Sep 2005 13:44:38 GMT
Hi Andy,

I agree that inheritance mapping 2 is missing some orm information wrt 
Employee relationships. Due to this lack, implementations cannot figure 
out the right runtime type at navigation time, e.g. navigating from 
Project to Employee.

For this reason we need to adapt the orm and the schema. Let's discuss 
this in tomorrow's t-conference. There are some options:

1) We drop identity column types from tables fulltimeemployees and 
parttimeemployees. We add fks between tables fulltimeemployees/persons 
and parttimeemployees/persons. We add orm inheritance joins between 
classes FullTimeEmployee/Person and PartTimeEmployee/Person. Question: 
Having these changes, does it still make sense to duplicate persons 
columns in tables fulltimeemployees and parttimeemployees?

2) We add orm relationship joins to all fields of type Employee. These 
join elements would contain information about the dynamic runtime type 
of the relationship. Question: Is the orm dtd descriptive enough to 
assign this information to join elements?

3) More options?

Regards,
Michael

>>I've not gone through the data created by the test, only the first few
>>records and the fact that it is creating these duplicate records (as I call
>>them). 
> 
> 
> Here's an issue for you Michael. This is the real issue behind our discussion 
> earlier. Hopefully this simplifies it all :-)
> 
> In the schema for "inheritance2" we have the Person class with its own table
> CREATE TABLE persons
> (
>     DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
>     ...
> )
> 
> and then we have the subclasses with these tables
> CREATE TABLE fulltimeemployees
> (
>     DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
>     ...
> )
> CREATE TABLE parttimeemployees
> (
>     DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
>     ...
> )
> 
> So when a JDO impl wants to insert a FullTimeEmployee object it will try to 
> insert a row into PERSONS, and the fact that you have IDENTITY on the column 
> will allocate an id. It will then try to insert into FULLTIMEEMPLOYEES, and 
> will try to allocate a (possibly different) identity since you have IDENTITY 
> on that table too!
> 
> Only the root table should have IDENTITY specified - in this case PERSONS. The 
> sub-tables should just be "DATASTORE_IDENTITY INTEGER NOT NULL". This is 
> correct in the schema for "inheritance3" and "inheritance4", but 
> "inheritance2" needs a fix.
> 
> 
> Returning to the issue of earlier, I had simply seen the above "IDENTITY" 
> specified on these two tables and raised the issue based on that (without 
> looking down to find any base table). The above change will mean that the 
> issue discussed before is likely _not_ going to affect us here since the ids 
> are actually assigned in the root table (PERSONS), and not in 
> PARTTIMEEMPLOYEE/FULLTIMEEMPLOYEE tables, and so you won't get clashes of 
> identity values between FullTime and PartTime employees - the id for a 
> PartTimeEmployee is assigned in the PERSONS table, and the id for a 
> FullTimeEmployee is assigned in the PERSONS table also. 
> Hope that clears it up!
> 
> 


-- 
-------------------------------------------------------------------
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/
-------------------------------------------------------------------

Mime
View raw message