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/10/05 16:33:48 UTC
Re: Inheritance test schema 2
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 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: Inheritance test schema 2
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
anything new on this topic?
Regards,
Michael
> Hi Andy,
>
> I like to summarize the intent of inheritance mapping 2 and inheritance
> mapping 3:
>
> The intent of mapping 2 is to guarantee fast object access wrt inserts,
> updates, deletes, and single selects (e.g. getObjectById). For this
> reason, mapping 2 does not require discriminator columns in where
> clauses as mapping 0 does. Moreover, no inheritance joins are required
> as in mapping 1. Instead, each table contains columns for declared and
> inherited fields.
>
> The intent of mapping 3 is to optimize mapping 1 wrt abstract classes.
> The differences between these mappings are that abstract classes are
> mapped to subclass tables in mapping 3. Inheritance joins are introduced
> from FullTimeEmployee to Person and from PartTimeEmployee to Person. Due
> to the existence of inheritance joins, mapping 3 guarantees unique PK
> values in the inheritance hierarchy.
>
> The drawback of mapping 2 is that it does not guarantee unique PKs
> values in the inheritance hierarchy. I'm not sure if identity strategy
> "increment" solves this issue, because there are 3 tables involved
> (persons, fulltimeemployees, parttimeemployees) which have to have
> unique PK values. Note, that there are no inheritance joins between
> these tables in mapping 2.
>
> That's why Craig proposed an implementation-defined sequence for this
> mapping. This sequence would be used by key generation for all involved
> tables (persons, fulltimeemployees, parttimeemployees). Moreover, Craig
> proposed a flag indicating if an implementation supports such a feature.
> The TCK would skip mapping 2 for implementation not supporting that
> feature.
>
> The current ORM does not support such sequences. The sequence attribute
> of element <datastore-identity> is reserved for database sequences. I
> think, if we include the concept of a named sequence class generating
> unique values for a set of tables, then implementations are able to
> handle relationship navigation in mapping 2.
>
> What do you think?
>
> Regards,
> Michael
>
>> Hi Michael,
>>
>>
>>> 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.
>>
>>
>>
>> OK. As I mentioned in the previous post, the only ones that will cause
>> issues are the identity column specifications for "fulltimeemployees"
>> and "parttimeemployees". If you want to change all of the person
>> inheritance tree tables to use, for example, "increment" identity
>> strategy then fine.
>>
>>
>>> 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?
>>
>>
>>
>> JPOX supports "subclass-table" inheritance on its own. JPOX (as of
>> yesterday) supports "subclass-table" inheritance combined with 1-N
>> relationships when there is at most 1 subclass of the collection
>> element class that has a table. Your example is for a 1-N relation
>> with the N side using "subclass-table" and there being *more than 1*
>> subclass (PartTimeEmployee, FullTimeEmployee). No, JPOX does not
>> currently support that. Sadly "inheritance2" and "inheritance3" are
>> both testing this situation.
>>
>> There are actually good reasons why this situation ("subclass-table"
>> with relationships) in general is not currently supported, not because
>> we're lazy and can't be bothered to implement it :-)
>> 1. it usually results in a schema that cannot have adequate FK
>> constraints imposed to guarantee referential integrity in the DB. In
>> designing any system I would avoid this combination because of just
>> this reason.
>> 2. it introduces significant added complexity to the retrieval of
>> objects, since there is no single base table to join to to find the
>> object in the collection
>>
>> That doesn't mean that we don't want to support it or that we won't
>> support it, but it's all down to prioritisation of issues and for the
>> reasons above this has always in the past been a low priority one for
>> us. For reference see these 2 JPOX JIRA issues
>> http://www.jpox.org/servlet/jira/browse/CORE-2446
>> http://www.jpox.org/servlet/jira/browse/CORE-2466
>>
>>
>
>
--
-------------------------------------------------------------------
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: Inheritance test schema 2
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
I like to summarize the intent of inheritance mapping 2 and inheritance
mapping 3:
The intent of mapping 2 is to guarantee fast object access wrt inserts,
updates, deletes, and single selects (e.g. getObjectById). For this
reason, mapping 2 does not require discriminator columns in where
clauses as mapping 0 does. Moreover, no inheritance joins are required
as in mapping 1. Instead, each table contains columns for declared and
inherited fields.
The intent of mapping 3 is to optimize mapping 1 wrt abstract classes.
The differences between these mappings are that abstract classes are
mapped to subclass tables in mapping 3. Inheritance joins are introduced
from FullTimeEmployee to Person and from PartTimeEmployee to Person. Due
to the existence of inheritance joins, mapping 3 guarantees unique PK
values in the inheritance hierarchy.
The drawback of mapping 2 is that it does not guarantee unique PKs
values in the inheritance hierarchy. I'm not sure if identity strategy
"increment" solves this issue, because there are 3 tables involved
(persons, fulltimeemployees, parttimeemployees) which have to have
unique PK values. Note, that there are no inheritance joins between
these tables in mapping 2.
That's why Craig proposed an implementation-defined sequence for this
mapping. This sequence would be used by key generation for all involved
tables (persons, fulltimeemployees, parttimeemployees). Moreover, Craig
proposed a flag indicating if an implementation supports such a feature.
The TCK would skip mapping 2 for implementation not supporting that feature.
The current ORM does not support such sequences. The sequence attribute
of element <datastore-identity> is reserved for database sequences. I
think, if we include the concept of a named sequence class generating
unique values for a set of tables, then implementations are able to
handle relationship navigation in mapping 2.
What do you think?
Regards,
Michael
> Hi Michael,
>
>
>>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.
>
>
> OK. As I mentioned in the previous post, the only ones that will cause issues
> are the identity column specifications for "fulltimeemployees" and
> "parttimeemployees". If you want to change all of the person inheritance tree
> tables to use, for example, "increment" identity strategy then fine.
>
>
>>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?
>
>
> JPOX supports "subclass-table" inheritance on its own.
> JPOX (as of yesterday) supports "subclass-table" inheritance combined with 1-N
> relationships when there is at most 1 subclass of the collection element
> class that has a table.
> Your example is for a 1-N relation with the N side using "subclass-table" and
> there being *more than 1* subclass (PartTimeEmployee, FullTimeEmployee). No,
> JPOX does not currently support that. Sadly "inheritance2" and "inheritance3"
> are both testing this situation.
>
> There are actually good reasons why this situation ("subclass-table" with
> relationships) in general is not currently supported, not because we're lazy
> and can't be bothered to implement it :-)
> 1. it usually results in a schema that cannot have adequate FK constraints
> imposed to guarantee referential integrity in the DB. In designing any system
> I would avoid this combination because of just this reason.
> 2. it introduces significant added complexity to the retrieval of objects,
> since there is no single base table to join to to find the object in the
> collection
>
> That doesn't mean that we don't want to support it or that we won't support
> it, but it's all down to prioritisation of issues and for the reasons above
> this has always in the past been a low priority one for us. For reference see
> these 2 JPOX JIRA issues
> http://www.jpox.org/servlet/jira/browse/CORE-2446
> http://www.jpox.org/servlet/jira/browse/CORE-2466
>
>
--
-------------------------------------------------------------------
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: Inheritance test schema 2
Posted by Andy Jefferson <an...@jpox.org>.
Hi Michael,
> 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.
OK. As I mentioned in the previous post, the only ones that will cause issues
are the identity column specifications for "fulltimeemployees" and
"parttimeemployees". If you want to change all of the person inheritance tree
tables to use, for example, "increment" identity strategy then fine.
> 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?
JPOX supports "subclass-table" inheritance on its own.
JPOX (as of yesterday) supports "subclass-table" inheritance combined with 1-N
relationships when there is at most 1 subclass of the collection element
class that has a table.
Your example is for a 1-N relation with the N side using "subclass-table" and
there being *more than 1* subclass (PartTimeEmployee, FullTimeEmployee). No,
JPOX does not currently support that. Sadly "inheritance2" and "inheritance3"
are both testing this situation.
There are actually good reasons why this situation ("subclass-table" with
relationships) in general is not currently supported, not because we're lazy
and can't be bothered to implement it :-)
1. it usually results in a schema that cannot have adequate FK constraints
imposed to guarantee referential integrity in the DB. In designing any system
I would avoid this combination because of just this reason.
2. it introduces significant added complexity to the retrieval of objects,
since there is no single base table to join to to find the object in the
collection
That doesn't mean that we don't want to support it or that we won't support
it, but it's all down to prioritisation of issues and for the reasons above
this has always in the past been a low priority one for us. For reference see
these 2 JPOX JIRA issues
http://www.jpox.org/servlet/jira/browse/CORE-2446
http://www.jpox.org/servlet/jira/browse/CORE-2466
--
Andy