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: collection of subclass-table
Date Mon, 05 Dec 2005 14:37:03 GMT
Hi Michael,

> I think, the intent of your proposal is to store the runtime type of the
> relationship together with the foreign key value in the database. You
> would replace a foreign key by a set of foreign keys. The set size would
> equal the number of subclasses. This would also apply to 1-1, 1-N
> relationhips not being contained in a jointable, e.g. manager, right?

Yes. This means that the treatment is then the same as how we handle reference 
(interface/Object) fields. This is the same situation exactly. The JDO2 spec 
says nothing, so the implementation is free to do it like that. It has the 
advantage that referential integrity is possible.

> I think, there are several optional ways to compute the runtime type of
> relationships:
> 1) FK per subclass (your proposal).
> 2) Discriminator per FK.
> 3) Union statement involving tables of all subclasses.

There are 2 issues. The first is how to store the information in the 
datastore, and the second is how to interpret the stored information (how to 
determine the runtime type for the datastore information).

So your option 3 is basically that there is a single column storing the id of 
the related object ? That means that referential integrity is not possible - 
you can't impose a FK from a single column to multiple element tables.

> I think, options 1) and 2) require the ORM DTD to be extended:

Well that depends if the JDO2 spec imposes what the schema should be with a 
1-1/1-N relation using subclass-table field/element. I don't see any need for 
a DTD change to use option 1. This is what we already use for reference 
fields (and collections of reference fields).

> When we discussed this issue the last time, we decided to go for option
> 3). This would be an optional feature that JDO implementations may
> support. For this reason, a new JDO option would be added to the spec.
> The TCK would check if the option is supported when mapping 2 is used

I agree with it being optional. I've said that for some time.

While it has been mentioned on jdo-dev, Option 3 was certainly not discussed 
by the EG. I certainly have no intention of using that. We've already 
implemented reference fields using multiple FKs. Implementing subclass-table 
the same way is the only way that makes sense to me. They should be 
consistent. I will be against any change in this implementation.

Java Persistent Objects - JPOX

View raw message