Here's what we're using for JPA:
// Contact Detail (root)
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name="object_type")
@PrimaryKeyJoinColumn(name="id", referencedColumnName="id")
// Address (subclass)
@DiscriminatorValue("ADR")
I guess JPA allows another approach, which would be to specify sql for
each subclass instead of a column value.
Reviewing what's out there already for single-table inheritance (which
I've never used before), I don't see any changes that are needed.
Everything that works for single-table seems to be sufficient and
necessary for vertical inheritance.
As far as I can tell, the implementation difference between
single-table and vertical is only that multiple tables are involved in
the queries for reading and writing the data.
I didn't completely understand the question, so I'm not sure if this answers it.
As I read through the JPA specs, I note that it does not support mixed
inheritance types for a set of tables as a required feature. This
could be future work if we decided we wanted to support it.
On Sun, May 30, 2010 at 1:44 PM, Andrus Adamchik <and...@objectstyle.org> wrote:
> Approaches to Mapping Inheritance
> ---------------------------------
>
> Currently we don't require users to specify inheritance semantics
> explicitly. We guess it instead (not unlike EOF). Just select a superclass
> ObjEntity and (optionally) subclass DbEntity and we'll derive the rest. In
> case of vertical inheritance I wrote the code to determine the inheritance
> DbRelationship out of all relationships between the super and sub tables
> (1..1 PK-based relationship).
>
> JPA for instance does require explicit inheritance semantics property set on
> the superclass. Should we do the same for sanity sake? E.g. to prevent
> unsupported combinations of inheritance types in a single hierarchy. I don't
> know what those unsupported combinations will be at the end (i.e. how smart
> our algorithms will end up being and how extensive the test suite we'll have
> to say what is supported and what's not). Having a hard rules (with
> validation done by the Modeler) will make things much less ambiguous (at the
> expense of some flexibility). E.g. back in the EOF days I barely used
> inheritance, as it was all based on implicit mapping rules between super and
> subclasses, so I never bothered to understand them (did it also require to
> flatten super attributes?? My current design won't).
>
> Thoughts on that?
