Yes, multiple levels will be supported in the suggested design. All I
was saying is that the JPA-style vertical inheritance approach seems
to imply a strict single-join-table-per-subclass mapping. While with
flattened attributes, you can (theoretically) mix and match where
subclass attributes are coming from.
Andrus
On Jun 1, 2010, at 12:32 PM, Mike Kienenberger wrote:
> 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 - 17:10:48 UTC