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