What I probably should do is create a simple project using
single-table inheritance, point it at a relevant subset of my current
project's schema structure, and see exactly what it looks like in the
modeler and in the generated code.
On Tue, Jun 1, 2010 at 12:32 PM, Mike Kienenberger <mkienen..mail.com> 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 - 16:35:31 UTC