Re: Vertical inheritance

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon May 31 2010 - 11:58:20 UTC

  • Next message: Andrus Adamchik: "Re: Vertical inheritance"

    As I think about this a little more...

    If you're talking about the inheritance chain, JPA appears to derive
    that from the java inheritance hierarchy. It's not explicitly
    defined.

    On Mon, May 31, 2010 at 7:48 AM, Mike Kienenberger <mkienen..mail.com> wrote:
    > Here's what we're using for JPA:
    >
    > // Contact Detail (root)
    >
    >..nheritance(strategy = InheritanceType.JOINED)
    >..iscriminatorColumn(name="object_type")
    >..rimaryKeyJoinColumn(name="id", referencedColumnName="id")
    >
    > // Address (subclass)
    >
    >..iscriminatorValue("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 <andru..bjectstyle.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?
    >



    This archive was generated by hypermail 2.0.0 : Mon May 31 2010 - 11:59:09 UTC