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 Andy Jefferson <an...@jpox.org> on 2005/09/27 20:56:08 UTC
Inheritance test schema 2 : "subclass-table" and "identity" strategy
The Schema 2 inheritance test provokes a question regarding
autoassign/identity strategy when using "subclass-table" strategy. We have 3
classes Employee, PartTimeEmployee, FullTimeEmployee. The Employee class uses
"subclass-table" and the 2 subclasses use "new-table" inheritance strategy.
This maps to 2 tables in the datastore
CREATE TABLE fulltimeemployees
(
DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
...
)
CREATE TABLE parttimeemployees
(
DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
...
)
OK, so what's the problem ?
Well, the problem is that "identity" strategy has been specifed in the ORM
file for both of these subclasses (and the DATASTORE_IDENTITY column is
IDENTITY too). This means that when we persist a FullTimeEmployee, an object
is inserted into "fulltimeemployees" and could be given id 1 (by the
datastore, since it is effectively managing "identity" strategy), and when we
insert a PartTimeEmployee, an object is inserted into "parttimeemployees" and
this could also be given id 1 (since the datastore manages that tables ids
too) !!! The "IDENTITY" keyword is managing ids for that RDBMS table only.
This would break many things. If I call getObjectById() passing in Employee,
and id value of 1 it wouldn't know which subclass it should use if we have DB
entries for a FullTimeEmployee (1) and a PartTimeEmployee (1).
Is the JDO impl supposed to guarantee uniqueness of ids in this situation ?
How ? For the case of the TCK it could be changed to "increment" strategy
maybe and then the JDO impl could manage these values itself perhaps. In the
real world the JDO impl could throw an exception in this situation (where
there is no "base" table that is effectively used to provide uniqueness of
ids in the inheritance tree)
Comments ?
--
Andy
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
Re: Inheritance test schema 2
Posted by Michael Watzek <mw...@spree.de>.
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,
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 Andy Jefferson <an...@jpox.org>.
> 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!
--
Andy
Re: Inheritance test schema 2 : "subclass-table" and "identity" strategy
Posted by Andy Jefferson <an...@jpox.org>.
Hi Michael,
> Preventing this situation, the inheritance proposal for mapping 2 puts
> some constraints on the object model which I summarized in mail
> "Inheritance proposal" sent on 8/8/2005. Obviously, we must document
> them in the wiki which has not been done yet. This is an excerpt:
>
> "- Mapping 2:
> ...
> Some additional constraints: Managers, mentors, hradvisors, and
> employees of the month are fulltime employees. Only fulltime employees
> can have insurances, can be project members, and can be project
> reviewers. Separate phone number type tables for persons, fulltime
> employees, and parttime employees."
>
> These constraints are reflected by the database schema for mapping 2. As
> there is no employees table, fks referencing employees in schema0
> reference either fulltimeemployees or parttimeemployees in schema2. In
> particular, there are 3 phone number tables in schema2, one referencing
> persons, one referencing fulltimeemployees, and one referencing
> parttimeemployees.
>
> Do these constraints solve your concerns?
Well in the datastore adding these restrictions on the FKs may have the effect
of limiting where an object can be stored (from the datastores point of
view), but how does the JDO implementation know this ? It has metadata -
there is nothing in the MetaData that defines that they can only be a
FullTimeEmployee. The MetaData (and the Java class) are the JDO input that
the JDO implementation works from. A "mentor" for example is an Employee
object type in a 1-1 relation mapped with a single FK (yes, I see your
restrictions in the schema SQL). The MetaData however doesn't specify
anything else. Consequently the JDO impl will always try to find the Employee
object that is at the other end of the relation. It will have to join with
both possible subclasses of Employee to find the one with the correct id.
Will this lead to issues with the data populated by the TCK test ?
You're expecting the JDO impl to go down through the users schema and find out
that the FK is to "FULLTIMEEMPLOYEES" and so eliminate any possible join to
"PATTIMEEMPLOYEES" ?
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).
Without analysing the data that the test is adding further I can't do any
more than point out these issues and the fact that there are many possible
issues with having FullTimeEmployee and PartTimeEmployee objects with the
same id. The simplest solution IMHO would be to choose an inheritance
strategy that allows the JDO implementation to keep them unique. I'm not
going to have any time to look further 'til early next week.
--
Andy
Re: Inheritance test schema 2 : "subclass-table" and "identity" strategy
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
> Hi Michael,
>
>
>>My understanding is that your scenario applies to datastore identity.
>>Applications can only construct objectid instances in case of
>>application identity. So, how would an application get an Employee
>>objectid instance?
>
>
> I was quoting one example of where things break in this situation. I can
> certainly create a datastore identity (of the JPOX OID type, since datastore
> id is JDO impl specific) with Employee as the class and 1 as the value. The
> fact remains that you're creating, by the specification of IDENTITY type, and
> "identity" strategy, objects which have the same "key" in their id in the
> same inheritance tree, and so issues will result. This was one example.
>
>
>>Do you agree that in case of datastore identity getObjectById can be
>>resolved for FullTimeEmployee/PartTimeEmployee objectid instances, even
>>if there are rows in tables fulltimeemployees and parttimeemployees
>>having the same pk values?
>
>
> I agree that *if* I have a full complete id with correct class, then I can
> find the row, since the class has been specified. What I'm saying is that
> there situations where you only have the "id" and not the class. The
> pm.getObjectById() is one example.
>
> Let's have another example :-)
> I've got a class (e.g Project) with a collection field and I'm storing objects
> of type Employee (declared in the metadata). I have a join table for storing
> the linkage between owner and element. I need to find the elements of the
> collection when retrieving the owner object. Now the only thing in the join
> table of use is a column which has the "id" of the Employee object that is
> contained in this collection. It doesn't say, "this is a FullTimeEmployee
> with id 1". It just says "its an Employee" (from the collection MetaData) and
> the FK column says "1" is the id of the object. So which element table do I
> join to ? Do I go to FULLTIMEEMPLOYEE ? Do I go to PARTTIMEEMPLOYEE ? How do
> i decide ?
Now I understand what you mean :-). You are completely right: That would
be an odd schema.
Preventing this situation, the inheritance proposal for mapping 2 puts
some constraints on the object model which I summarized in mail
"Inheritance proposal" sent on 8/8/2005. Obviously, we must document
them in the wiki which has not been done yet. This is an excerpt:
"- Mapping 2:
...
Some additional constraints: Managers, mentors, hradvisors, and
employees of the month are fulltime employees. Only fulltime employees
can have insurances, can be project members, and can be project
reviewers. Separate phone number type tables for persons, fulltime
employees, and parttime employees."
These constraints are reflected by the database schema for mapping 2. As
there is no employees table, fks referencing employees in schema0
reference either fulltimeemployees or parttimeemployees in schema2. In
particular, there are 3 phone number tables in schema2, one referencing
persons, one referencing fulltimeemployees, and one referencing
parttimeemployees.
Do these constraints solve your concerns?
Regards,
Michael
>
> Having duplicate id "values" in an inheritance tree representing different
> objects is a "bad thing".
>
>
--
-------------------------------------------------------------------
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 : "subclass-table" and "identity" strategy
Posted by Andy Jefferson <an...@jpox.org>.
Hi Michael,
> My understanding is that your scenario applies to datastore identity.
> Applications can only construct objectid instances in case of
> application identity. So, how would an application get an Employee
> objectid instance?
I was quoting one example of where things break in this situation. I can
certainly create a datastore identity (of the JPOX OID type, since datastore
id is JDO impl specific) with Employee as the class and 1 as the value. The
fact remains that you're creating, by the specification of IDENTITY type, and
"identity" strategy, objects which have the same "key" in their id in the
same inheritance tree, and so issues will result. This was one example.
> Do you agree that in case of datastore identity getObjectById can be
> resolved for FullTimeEmployee/PartTimeEmployee objectid instances, even
> if there are rows in tables fulltimeemployees and parttimeemployees
> having the same pk values?
I agree that *if* I have a full complete id with correct class, then I can
find the row, since the class has been specified. What I'm saying is that
there situations where you only have the "id" and not the class. The
pm.getObjectById() is one example.
Let's have another example :-)
I've got a class (e.g Project) with a collection field and I'm storing objects
of type Employee (declared in the metadata). I have a join table for storing
the linkage between owner and element. I need to find the elements of the
collection when retrieving the owner object. Now the only thing in the join
table of use is a column which has the "id" of the Employee object that is
contained in this collection. It doesn't say, "this is a FullTimeEmployee
with id 1". It just says "its an Employee" (from the collection MetaData) and
the FK column says "1" is the id of the object. So which element table do I
join to ? Do I go to FULLTIMEEMPLOYEE ? Do I go to PARTTIMEEMPLOYEE ? How do
i decide ?
Having duplicate id "values" in an inheritance tree representing different
objects is a "bad thing".
--
Andy
Re: Inheritance test schema 2 : "subclass-table" and "identity" strategy
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
> Hi Michael,
>
>
>>>This would break many things. If
>>>I call getObjectById() passing in Employee, and id value of 1 it wouldn't
>>>know which subclass it should use if we have DB entries for a
>>>FullTimeEmployee (1) and a PartTimeEmployee (1).
>>
>>I'm not sure what you mean by "getObjectById() passing in Employee".
>>The object model specifies that class Employee is abstract. Thus, there
>>cannot exist persistent instances of Employee which are not instances of
>>Employee subclasses. This means that there are no object id instances
>>of class Employee.
>
>
> I mean that any user can call pm.getObjectById(id), and they could construct
> an "id" where the id is created as being for Employee with value "1". They
> would do this if they knew they had an instance of Employee (or subclass)
> that has an id of 1.
My understanding is that your scenario applies to datastore identity.
Applications can only construct objectid instances in case of
application identity. So, how would an application get an Employee
objectid instance?
Do you agree that in case of datastore identity getObjectById can be
resolved for FullTimeEmployee/PartTimeEmployee objectid instances, even
if there are rows in tables fulltimeemployees and parttimeemployees
having the same pk values?
The JDO impl then has to go off, realise that there are
> no implementations of Employee as such, and find the right subclass for this
> object.
> There should be *no way* of having a FullTimeEmployee with id "1" _and_ a
> PartTimeEmployee with id "1". They are 2 different objects and the id should
> be unique in an inheritance tree.
My understanding is that this applies to application identity only.
There, you have the same objectid class for all classes in an
inheritance hierarchy.
Regards,
Michael
With the situation in this test case
> currently they aren't, because there are 2 root tables (in this inheritance
> tree) and both are defined as having "IDENTITY" columns, so whenever anything
> is inserted into either a new id is allocated in that particular table
> (independent of the identity values allocated in the other table).
>
> It would work fine if Employee had its own table since then there is 1 root
> table EMPLOYEE which would be the only table using IDENTITY. Sadly once you
> include subclass-table at the root level you get this problem. "autoassign"
> and "identity" both imply using the underlying datastore mechanisms and both
> will fall foul of this problem.
>
>
--
-------------------------------------------------------------------
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 : "subclass-table" and "identity" strategy
Posted by Andy Jefferson <an...@jpox.org>.
Hi Michael,
> > This would break many things. If
> > I call getObjectById() passing in Employee, and id value of 1 it wouldn't
> > know which subclass it should use if we have DB entries for a
> > FullTimeEmployee (1) and a PartTimeEmployee (1).
>
> I'm not sure what you mean by "getObjectById() passing in Employee".
> The object model specifies that class Employee is abstract. Thus, there
> cannot exist persistent instances of Employee which are not instances of
> Employee subclasses. This means that there are no object id instances
> of class Employee.
I mean that any user can call pm.getObjectById(id), and they could construct
an "id" where the id is created as being for Employee with value "1". They
would do this if they knew they had an instance of Employee (or subclass)
that has an id of 1. The JDO impl then has to go off, realise that there are
no implementations of Employee as such, and find the right subclass for this
object.
There should be *no way* of having a FullTimeEmployee with id "1" _and_ a
PartTimeEmployee with id "1". They are 2 different objects and the id should
be unique in an inheritance tree. With the situation in this test case
currently they aren't, because there are 2 root tables (in this inheritance
tree) and both are defined as having "IDENTITY" columns, so whenever anything
is inserted into either a new id is allocated in that particular table
(independent of the identity values allocated in the other table).
It would work fine if Employee had its own table since then there is 1 root
table EMPLOYEE which would be the only table using IDENTITY. Sadly once you
include subclass-table at the root level you get this problem. "autoassign"
and "identity" both imply using the underlying datastore mechanisms and both
will fall foul of this problem.
--
Andy
Re: Inheritance test schema 2 : "subclass-table" and "identity" strategy
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
> The Schema 2 inheritance test provokes a question regarding
> autoassign/identity strategy when using "subclass-table" strategy. We have 3
> classes Employee, PartTimeEmployee, FullTimeEmployee. The Employee class uses
> "subclass-table" and the 2 subclasses use "new-table" inheritance strategy.
> This maps to 2 tables in the datastore
>
> CREATE TABLE fulltimeemployees
> (
> DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
> ...
> )
>
> CREATE TABLE parttimeemployees
> (
> DATASTORE_IDENTITY INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
> ...
> )
>
> OK, so what's the problem ?
>
> Well, the problem is that "identity" strategy has been specifed in the ORM
> file for both of these subclasses (and the DATASTORE_IDENTITY column is
> IDENTITY too). This means that when we persist a FullTimeEmployee, an object
> is inserted into "fulltimeemployees" and could be given id 1 (by the
> datastore, since it is effectively managing "identity" strategy), and when we
> insert a PartTimeEmployee, an object is inserted into "parttimeemployees" and
> this could also be given id 1 (since the datastore manages that tables ids
> too) !!! The "IDENTITY" keyword is managing ids for that RDBMS table only.
> This would break many things. If I call getObjectById() passing in Employee,
> and id value of 1 it wouldn't know which subclass it should use if we have DB
> entries for a FullTimeEmployee (1) and a PartTimeEmployee (1).
I'm not sure what you mean by "getObjectById() passing in Employee".
The object model specifies that class Employee is abstract. Thus, there
cannot exist persistent instances of Employee which are not instances of
Employee subclasses. This means that there are no object id instances
of class Employee.
Maybe you mean that two datastore objectid instances, one for
FullTimeEmployee and the other for PartTimeEmployee, having the same
value in the database wrt their identity columns (e.g. 1) would equal in
the object model?
Regards,
Michael
>
> Is the JDO impl supposed to guarantee uniqueness of ids in this situation ?
> How ? For the case of the TCK it could be changed to "increment" strategy
> maybe and then the JDO impl could manage these values itself perhaps. In the
> real world the JDO impl could throw an exception in this situation (where
> there is no "base" table that is effectively used to provide uniqueness of
> ids in the inheritance tree)
>
> Comments ?
>
--
-------------------------------------------------------------------
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/
-------------------------------------------------------------------