Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Wed May 30 2007 - 21:54:15 EDT

  • Next message: Lachlan Deck: "Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]"

    On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote:

    > On 5/30/07, Aristedes Maniatis <ar..aniatis.org> wrote:
    >> When we get to vertical inheritance there will be at least one other
    >> property added to the ObjEntity: the name of the relationship used to
    >> find the superclass.
    >
    > When we get to inheritance, we'd be wise to follow the JPA methodology
    > for specifying inheritance relationships. Vertical and single-table
    > is well-defined.

    Fair enough.

    <disclaimer>I'm coming from years in the land of EOF where for
    vertical inheritance there is indeed a relationship to the parent.
    But this was needed, I suppose, in order to flatten the parent's
    attributes/relationships into the child; but there's not much
    difference, conceptually, for mapping inheritance</disclaimer>

    So really (if that idea was switched for something more JPA friendly)
    the Inheritance strategy [as I mentioned in the original email
    'Modelling improvements: inheritance + interfacing (Draft)'] is still
    easy determined by these simple conditions:
    a) is the parent ObjEntity mapped to the same DbEntity?
    b) is the parent ObjEntity mapped to a DbEntity at all?

    e.g.,
    a == YES, b == YES --> Inheritance.SINGLE_TABLE
    a == NO, b == NO --> Inheritance.TABLE_PER_CLASS
    a == NO, b == YES --> Inheritance.JOINED

    ... and together with the further condition (isAbstract) also
    determines whether we're doing a deep fetch, plus whether there's an
    @DiscriminatorColumn etc.

    Okay, so consider the request for superRelationship dropped. (See
    disclaimer :-) Well that makes it simpler to do all of this ;-)

    > I can't remember if the optional horizontal
    > relationships are spelled out in the spec.

    from: http://java.sys-con.com/read/286901.htm
    - SINGLE_TABLE: Single-table-per-class inheritance hierarchy. This is
    the default strategy. The entity hierarchy is essentially flattened
    into the sum of its fields, and these fields are mapped down to a
    single table.
    - JOINED [1]: Common base table, with joined subclass tables. In this
    approach, each entity in the hierarchy maps to its own dedicated
    table that maps only the fields declared on that entity. The root
    entity in the hierarchy is known as the base table, and the tables
    for all other entities in the hierarchy join with the base table.
    - TABLE_PER_CLASS [2]: Single-table-per-outermost concrete entity
    class. This strategy maps each leaf (i.e., outermost, concrete)
    entity to its own dedicated table. Each such leaf entity branch is
    flattened, combining its declared fields with the declared fields on
    all of its super-entities, and the sum of these fields is mapped onto
    its table.

    [1] vertical inheritance
    [2] horizontal inheritance

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Wed May 30 2007 - 21:54:46 EDT