[odb-users] Inheritance

[Kuentzer, Jan]

Hi Boris,

> The first approach doesn't really require changes to the base classes.
> Underneath the ORM layer, however, all these classes are mapped to a single table,
> so when you add a new derived class, that table has to be extended with
> additional columns. 
> With the first approach (single table per hierarchy), all the operations (load, update,
> query, etc) will require a single statement (select, update, etc). With the second
> approach, the load/query operations can be implemented only as several queries
> or using joins, both of which are more expensive than a single simple query. For
> update, we will always need several update statements. With the third approach the
> load/query operations are even more complex/expensive while update goes back
> to a single statement.

Okay I misunderstood. If the first approach does not require any change to the base classes I guess the first approach with the single tables would be the one I would use since it is the fastest.

> The idea behind emulation is to encode the object type into the id. This
> way, when you load the object, you can first figure out its actual type
> and then load it from the database. In this approach you cannot use the
> automatically-assigned ids for the hierarchy, and all objects in the
> hierarchy must share the same id space. 
> Finally, in order to have a polymorphic object relationship, you will
> need to emulate it by having a persistent member that is the object
> id and a transient member which is the actual pointer:
> 
> #pragma db object
> class employer
> {
>   ...
> 
>   unsigned long long ceo_id_;
> 
>   #pragma db transient
>   employee* ceo_;
> };
> 
> You will then need to use the load_employee() function to load the ceo_
> pointer. For the next release of ODB we have added support for user
> callbacks. This feature will allow you to handle such loading
> transparently.

Okay, I understand the idea. We already have an attribute with an id we can easily change to contain the type as you suggested.
The additional object id and the transient pointer are necessary because the pointer would be loaded as an employee by ODB? If I load an object with vector<employee*> I will have to load all of them recursively.
You said the next release will support polymorphic object relationship and/or transparent loading. Can you already say when you plan to release the next version? A few weeks or next year?

Thanks

          Jan