db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Issue 138: Names of optional features
Date Wed, 08 Feb 2006 20:04:54 GMT
Hi Andy,

On Feb 2, 2006, at 4:46 AM, Andy Jefferson wrote:

> Hi Craig,
>> Heterogeneous collections with new-class mapping of subclasses
>> javax.jdo.option.mapping.JoinedTablePerClass (this is tck schema1)
>> javax.jdo.option.mapping.JoinedTablePerConcreteClass (this is tck  
>> schema3)
>> javax.jdo.option.mapping.NonJoinedTablePerConcreteClass (this is  
>> tck schema2)
> These names mean nothing to me. I would personally prefer something  
> using the
> inheritance-strategy names. e.g
> javax.jdo.option.mapping.RelationNewTable
> javax.jdo.option.mapping.RelationSubclassTable
> javax.jdo.option.mapping.RelationSuperclassTable
> (I think that's what these 3 inheritance schema TCK tests were for)
> Just wondered whether it's only me who hasn't a clue what a
> "NonJoinedTablePerConcreteClass" means :-)

The problem with your approach is that your descriptions don't match  
the semantics of the restrictions. The subclass-table metadata  
attribute is used for cases of joined and non-joined tables, and the  
restrictions are most likely on non-joined tables. Specifically, if  
you have a concrete Person, abstract Employee, and concrete  
FullTimeEmployee, you can map Employee fields to subclasses and map  
to PERSON and FULLTIMEEMPLOYEE that either have a join relationship  
or non-join relationship. I believe that JPOX supports subclass-table  
but not NonJoinedTablePerConcreteClass.

The names in the optional features list would be fully described in  
Chapter 11 but I was looking for a shorthand description. I looked in  
the JSR 220 spec and they use SINGLE_TABLE, JOINED, and  
TABLE_PER_CLASS as their enum descriptions. Their JOINED actually  
encompasses my JoinedTablePerClass and JoinedTablePerConcreteClass  
which I think are actually two different cases.
>> Mapping fields of Object type and interface types
>> javax.jdo.option.mapping.HeterogeneousObjectType (no tck tests yet)
>> javax.jdo.option.mapping.HeterogeneousInterfaceType (no tck tests  
>> yet)
> What do these mean exactly ?
> Support for a field of type java.lang.Object with
> multiple possible PC types that
> can be stored in that field ?

Yes. This is not portable so it's not clear that it is possible to  
have a TCK test for it.

> Support for a field of type interface with multiple possible PC  
> implementations
> that can be stored in that field ?


> No problem with the names, as long as we have a definition.

The idea is that there would be a paragraph in the specification in  
Chapter 11 that describes the behavior that is implied by  
implementing each feature.

My next revision of this issue will include the Chapter 11  

> -- 
> Andy

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message