Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43971CFC.8030701@spree.de>
Date: Wed, 07 Dec 2005 18:33:48 +0100
From: Michael Watzek <mwa.tech@spree.de>
Organization: Tech@Spree GmbH
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
Subject: Inheritance mapping 3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

inheritance mapping 3 is an optimization of mapping 1:

Mapping 1 specifies a table for each class in the inheritance hierarchy. 
These tables only contain columns for the declared fields. Tables of 
subclasses refer tables of superclasses via FKs.

In contrast, mapping 3 only specifies tables for concrete classes. 
Fields of abstract classes are mapped by inheritance strategy 
subclass-table.

As class Insurance is abstract, it is not mapped to its own table in 
mapping 3. Instead, its fields are mapped to tables dentalinsurance and 
medicalinsurance. Due to the fact that class Insurance is the top most 
class in the inheritance hierarchy, tables dentalinsurance and 
medicalinsurance do not specify inheritance FKs.

For this reason, it seems that the insurance hierarchy in mapping 3 has 
the same problem as the person hierarchy in inheritance mapping 2: There 
are not discriminator columns and there are not inheritance FKs. This 
means that implementations must support union joins for relationship 
navigation in order to retrieve the runtime type. As a consequence, the 
TCK would have to check for union join support when mapping 3 is 
executed (as we decided for mapping 2).

However, there is a little difference on how the company model handles 
insurance relationships vs. employee relationships: Insurance 
relationships are specified to leaf classes of the inheritance hierarchy 
(DentalInsurance and MedicalInsurance). For this reason, the runtime 
type of an insurance relationship is the same as the declared type.

Thus, I'm not sure on how to proceed with mapping 3. There are several 
options:

1) Drop mapping 3.
2) Make mapping 3 optional as we decided for mapping 2.
3) Leave it as is.

What do you think?

Regards,
Michael
-- 
-------------------------------------------------------------------
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/
-------------------------------------------------------------------