[odb-users] Issue wth migration of std.array newly added members

Boris Kolpackov boris at codesynthesis.com
Tue Jun 3 07:04:07 EDT 2025


OLBINSKI Gracjan <gracjan.olbinski-ext at hexagon.com> writes:

>   1.  I have an object stored in the database under schema version 41.
>
>   2.  In version 42, I introduced a new data member of type
>       std::array<double, 3>, which shall be initialized to {0, 0, 0} by
>       default.
>
>   3.  During the migration process, ODB correctly creates the shadow
>       table for the object, but it remains empty after migration.
>
>   4.  When attempting to load objects from the migrated database in a debug
>       build, the application fails with an assertion in
>       std_array_traits.hxx:50, which checks that all array elements are
>       properly populated from the database.
>
>   5.  Due to this assertion failure, it’s not possible to manually complete
>       the migration by inserting the missing values into the shadow table,
>       as the application crashes (due to assertion) before any such logic
>       can be executed.

Yes, interesting situation. In a sense, the type's invariants preclude you
from "fixing up" the temporarily invalid state during the schema migration.
Typically, this "absent value in the database" situation is resolved with
NULL-able members. The equivalent for a container would be a container type
that allows empty content.


> The only workaround that I can think of is execution of raw sql statement
> via db->execute() api to insert missing rows to shadow table.

Yes, this is probably the simplest if not very elegant solution. Another,
more elaborate, option would be to use a lazy-loaded section and put the
container there:

https://www.codesynthesis.com/products/odb/doc/manual.xhtml#9

The idea is to load the object but not the section, then initialize the
container, manually mark the section as loaded, and update the object.

You would have to keep the section around (and manually load it whenever
loading the object) for as long as you support this migration step (41->42
in your case) but once that step is no longer supported, you can drop
the section.



More information about the odb-users mailing list