cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <>
Subject Re: Vertical inheritance
Date Mon, 31 May 2010 11:48:21 GMT
Here's what we're using for JPA:

// Contact Detail (root)

@Inheritance(strategy = InheritanceType.JOINED)
@PrimaryKeyJoinColumn(name="id", referencedColumnName="id")

// Address (subclass)


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

View raw message