Hi Craig, > 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.
* JPOX supports "superclass-table", "new-table", and "subclass-table" as an inheritance strategy so you can have objects in a tree using those. * JPOX doesn't support a class with a field that relates to an object of a type using subclass-table strategy. * JPOX supports classes with fields that relate to objects of a type using superclass-table, or new-table. e.g If you have Department with a list of Employees, with Department with an employees field defined with element-type of Employee. JPOX supports Employee uses inheritance strategy of new-table/superclass-table. It doesn't support that relation where Employee uses subclass-table. That is what I was trying to distinguish. As long as that is specifiable using your categories then I'm happy. > The names in the optional features list would be fully described in > Chapter 11 but I was looking for a shorthand description. Excellent, then it's not an issue. -- Andy
