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