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 16:23:59 GMT
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/
-------------------------------------------------------------------

Mime
View raw message