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