Re: Vertical inheritance

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Jun 04 2010 - 21:05:14 UTC

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

    Hi Lachlan,

    thanks for the feedback. I think I'll be moving ahead with this design
    (and I wish I had more time for Cayenne work in general)...

    Andrus

    On Jun 2, 2010, at 10:43 PM, Lachlan Deck wrote:

    > On 01/06/2010, at 11:38 PM, Andrus Adamchik wrote:
    >
    >> On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote:
    >>
    >>> BTW, semantically "vertical inheritance with discriminator" is
    >>> essentially single-table inheritance with flattened attributes in
    >>> subclasses. Which Cayenne supports already, but without any
    >>> special optimizations for wide|deep hierarchies.
    >>
    >> Pounding on this idea some more ... Since we can't get away from
    >> using entity qualifier (discriminator) at least in some cases for
    >> performance reasons, and I hate to add multiple strategies, maybe
    >> we do make the qualifier required and treat vertical as a special
    >> case of single table with subclasses mapped to the same root table,
    >> and having flattened attributes mapped to subclass-specific table.
    >> The benefits of that are:
    >>
    >> * No implicit inheritance relationship from super to sub table. It
    >> is explicitly mapped inside flattened attributes.
    >> * More intuitive mapping, easier to visualize attributes, as all
    >> attributes are rooted in the same base table.
    >> * Can potentially handle more than one joined table per subclass,
    >> or the same join table for multiple subclasses, or a mix of single
    >> table mapping with joined table mapping. I.e. in the spirit of
    >> Cayenne, we'd allow users to follow a generic DB semantics in their
    >> mapping instead of forcing an arbitrary ORM concepts on a (legacy)
    >> DB schema.
    >> * No new concepts for the backend or Modeler to deal with.
    >
    > +1
    >
    >> Now we still need to do some work with this design:
    >>
    >> * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with
    >> flattened attributes over 1..1 relationships, and especially when
    >> inheritance is involved.
    >> * Add convenience Modeler methods to flatten all attributes at once
    >> for a given relationship to simplify subclass mapping.
    >> * Add performance optimizations per Mike's idea, limiting the
    >> number of joins done in a single query.
    >>
    >> Mike, do you see any holes in this design?
    >
    > Looks good.
    >
    > with regards,
    > --
    >
    > Lachlan Deck
    >
    >



    This archive was generated by hypermail 2.0.0 : Fri Jun 04 2010 - 21:05:47 UTC