You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2010/06/01 15:38:42 UTC
Re: Vertical inheritance
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
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <andrus@objectstyle.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
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mk...@gmail.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 <an...@objectstyle.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
>>
>>
>
Re: Vertical inheritance
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <an...@objectstyle.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
>
>
Re: Vertical inheritance
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
Re: Vertical inheritance
Posted by Lachlan Deck <la...@gmail.com>.
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