I'm not complete certain I understand the design -- I don't have any
experience with single-table inheritance. It sounds ok for as much
as I do understand. The only concern I have is that the wording
below seems to indicate that only two tables are involved (the root
table and the subclass table), but any vertical inheritance deeper
than two would involve more tables (N classes deep is N tables). I'm
99.9% certain that you already know this, so I am certain that I'm
just misreading your message. But I figure I better ask just in case
I'm wrong.
On Tue, Jun 1, 2010 at 9:38 AM, Andrus Adamchik <andru..bjectstyle.org> 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.
>
> 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?
>
> Cheers,
> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Tue Jun 01 2010 - 16:32:56 UTC