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 theinheritance-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 implementationsthat 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
