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 <[email protected]
> 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
