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 ?

Yes.

> 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  
description...

Craig
>
>
> -- 
> 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!


Mime
View raw message