cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Vertical inheritance
Date Tue, 01 Jun 2010 17:10:17 GMT
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.


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 < 
> > 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

View raw message