Unable to combine abstract and polymorphic base types

[N40]

I have an issue or a question regarding a mix of polymorphic and abstract inheritance

considering the

#pragma db object abstract
struct Traits_A

#pragma db object
struct Traits_B

#pragma db object
struct Target : Traits_A, Traits_B

yields the desired .cxx code

bind<Target> (...)
{
  // Traits_A base
  object_traits_impl< ::Traits_A, id_sqlite >::bind (b + n, i, sk);

  // Traits_B base
  object_traits_impl< ::Traits_B, id_sqlite >::bind (b + n, i, sk);

WHEREAS

#pragma db object polymorphic
struct Base

#pragma db object
struct Traits_B

#pragma db object
struct Target : Base, Traits_B

yields omitting the Traits B abstract

bind<Target> (...
{

  // Base base
  base_traits::bind (b + n, *i.base, sk);
}

Is there a rule, that inheriting from one polymorphic class omits all other inheritances on the same level?

[boris-kolpackov]

There is a section on this in the documentation: https://www.codesynthesis.com/products/odb/doc/manual.xhtml#8.3

Also note that polymorphism inheritance is handled differently compared to what you seem to expect. In particular, in the above example, Base will be stored in its own table and thus its members won't be bound when storing Target. I suggest that you read (or re-read) the relevant section in the documentation: https://www.codesynthesis.com/products/odb/doc/manual.xhtml#8.2

[N40]

Thank you for the answer!

I had already read the chapter 8.2 and 8.3.

I apologize for the not specified question:

what is the technical necessity of blocking abstract inheritance in the TOP (derived) part of an hierarchy, when there was a polymorphic inheritance somewhere in the BOTTOM (base).

I am aiming for the mixin pattern here, where a Base class is providing polymorphic DB code and the derived classes inheriting from it are built using abstract mixin trait classes.

---

My minimal code elaborating my question

#pragma db object polymorphic
struct Base
{
  virtual ~Base() {}
  #pragma db member id
  int ta;
};

#pragma db object abstract
struct Traits_B // some mixing stuff
{
  int tb;
};

#pragma db object
struct Target : Base, Traits_B
{
};

yields the i.cxx content

void access::object_traits_impl< ::Target, id_sqlite >::
  init (object_type& o,
        const image_type& i,
        database* db,
        std::size_t d)
  {
    ODB_POTENTIALLY_UNUSED (o);
    ODB_POTENTIALLY_UNUSED (i);
    ODB_POTENTIALLY_UNUSED (db);

    // Base base
    //
    if (--d != 0)
      base_traits::init (o, *i.base, db);
  }

I would aim for the result having an entry // Traits_B base there as well.

Omitting the polymorphic for Base does exactly this.

The weird thing is, that the auto-generated DB schema looks like this

          db.execute ("CREATE TABLE \"Target\" (\n"
                      "  \"tb\" INTEGER NOT NULL,\n"
                      "  \"ta\" INTEGER NOT NULL PRIMARY KEY,\n"
                      "  CONSTRAINT \"ta_fk\"\n"
                      "    FOREIGN KEY (\"ta\")\n"
                      "    REFERENCES \"Base\" (\"ta\")\n"
                      "    ON DELETE CASCADE)");

So apparently mixing both inheritance styles does only partially work?

[boris-kolpackov]

what is the technical necessity of blocking abstract inheritance in the TOP (derived) part of an hierarchy, when there was a polymorphic inheritance somewhere in the BOTTOM (base).
So apparently mixing both inheritance styles does only partially work?

It's not "blocked", it most likely just not handled in all the corners (which is the reason why in some parts you get the correct result). And the reason it is not handled is complexity: it's not worthwhile spending a lot of effort (both on initial support and ongoing maintenance) to handle something that will be used by one person (so far you are the first asking for this).

Also if you really need to have this inheritance structure, you can still make it work by keeping Traits_B transient and then replicating its members in Target using virtual data member.