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 : "subclass-table" and "identity" strategy
Date Wed, 28 Sep 2005 15:03:03 GMT
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.

  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/

View raw message