[odb-users] Polymorphic inheritance

[Wesley Harris]

Hi Boris

I really like emailing this list: everytime I do, the features I want are
in the next release :) Thanks for all your hard work!

I would be very interested in trying it out, as the project I am working on
requires polymorphic inheritance. For my current needs, table per heirarchy
would be fine as the child classes are mainly different in their behavior.
That being said, I would prefer the flexibility of the other approaches in
the event that TPH does not meet my needs. Thus, for my current project,
the flexibility and space saving benifits of table per difference would be
most benificial (especially as I am passing off the database access to a
background thread to reduce the persistance latency).

Looking forward to the release!

Wesley



On Wed, Feb 29, 2012 at 7:52 PM, Boris Kolpackov <boris at codesynthesis.com>wrote:

> Hi Wesley,
>
> Wesley Harris <wesmharris at gmail.com> writes:
>
> > I noticed that the docs say that polymorphic inheritance is not yet
> > supported. Is there any time frame on when it will be implemented?
>
> We are actually planning to add this support for the next release and
> I hope to have something ready to try in a few weeks, if you are
> interested.
>
> Also, there are generally three different approaches to modeling
> polymorphic inheritance in the database:
>
> 1. Table per hierarchy, where all derived objects belonging to a
>   hierarchy are stored in a single table.
>
> 2. Table per difference, where additional columns corresponding to
>   the derived classes are stored in additional tables.
>
> 3. Table per class, where each class in a hierarchy gets its own
>   independent table that contains all its members.
>
> The first approach is the most inflexible: you have to provide the so-
> called discriminator (basically a value that distinguishes different
> classes) and the whole hierarchy must be known at compile-time (e.g.,
> reside in a single header or similar). But it is also the most
> efficient in terms of the database statements that need to be
> executed.
>
> The second and third approaches are more flexible but are generally
> not as efficient as the first one.
>
> Do you have any preference as to which approach would work best in
> your case?
>
> Boris
>