cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Vertical inheritance
Date Fri, 04 Jun 2010 21:05:14 GMT
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
>
>


Mime
View raw message