Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
From: Andy Jefferson <andy@jpox.org>
To: jdo-dev@db.apache.org
Subject: Re: Inheritance test schema 2
Date: Sat, 8 Oct 2005 09:26:59 +0100
User-Agent: KMail/1.7.2
References: <200509271956.08562.andy@jpox.org> <433BEFC6.4020706@spree.de>
 <4343E44C.5090806@spree.de>
In-Reply-To: <4343E44C.5090806@spree.de>
Organization: JPOX
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510080926.59915.andy@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