Hi Andy,
in last t-conference, we decided to file a JIRA
(http://issues.apache.org/jira/browse/JDO-167) on this issue.
Craig proposed to drop the identity types on the PK columns of tables
persons, fulltimeemployees, and parttimeemployees. Instead, an
implementation-defined sequence should be used to generate unique PK
values for the three tables.
My understanding is that we do not introduce FKs from parttimeemployees
to persons and from fulltimeemployees to persons. Also, we do not
introduce inheritance <join> elements in the ORM for FullTimeEmployee
and PartTimeEmployee.
Does JPOX support such a mapping?
Regards,
Michael
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/
-------------------------------------------------------------------
