db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: Inheritance test schema 2 : "subclass-table" and "identity" strategy
Date Wed, 28 Sep 2005 17:24:14 GMT
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 

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.


View raw message