[odb-users] Schema migration of sub-class (adding attributes)

[Paul Stath]

Hi all,

I am having an issue with schema migration related to polymorphic classes  that I have found a work-around for, but I'm wondering if there is a better way.

#pragma db object optimistic
class Request {
    #pragme db value_not_null inverse(request)
   std::set<Group>                           groups_;  // to many
};

#pragma db object optimistic abstract polymorphic
class Group {
    #pragma db not_null on_delete(cascade)
    std::weak_ptr<Request>          request_; // to one

    #pragma db value_not_null inverse(group)
    std::set<Detail>                           details_; // to many
};

#pragma db object polymorphic
Class GroupA : public Group {};

#pragma db object polymorphic
Class GroupB : public Group {};

class Detail {
    std::weak_ptr<Group>              group_; // to one
}

I am attempting to load a Detail record, which in turn loads the parent Group object and then the parent Request object.

In a subsequent version of the schema, I soft-add columns to the GroupB object, but the Group base class still has the original (version 1) schema.

When loading a persisted Detail record with a foreign key that points to a GroupB record in the database,
I get a segmentation violation trying to construct the GroupB object from the database row.

I am able to avoid the issue by soft-adding an unused attribute to the Group base class.

I suspect that since the Group base class doesn't have any schema version soft add/deletes,
the code generated to load the inverse related object doesn't appear to use the method signatures that include the "svm" parameter.

Is this a known issue?   If not when I have time I'll create a minimal test that re-creates the issue.
Is there a way to force the use of the "svm" method signatures for a class other than having added/deleted pragmas in the base class?

I noticed a "force_versioned" variable in the ODB plug-in source that would seem to force a class to be considered versioned,
but I can't determine a way to cause it to be true.

Any advice would be appreciated.

--- Paul Stath