[odb-users] Schema evolution and upward compatibility

[Boris Kolpackov]

Hi Christian,

Christian Sell <christian at gsvitec.com> writes:

> By this I mean that an older application will be able to access a
> newer schema and still behave gracefully.

Just to make it clear, ODB doesn't "officially" support this mode
and probably never will; the "normal" direction is already complex
enough.


> Now, I understand that this will only work if the application has
> been designed with that compatibility in mind [...]

Right, you will at the least have to make sure that the new schema
if always a superset of the old one. That is, not remove any objects,
data members, etc. Even then, you can run into breakages. For example,
the new version of the object might contain a non-NULLable pointer
that the old code will fail to persist. So it seems like besides
not removing anything, whatever new data members you add, they all
should have default values (see 'default' pragma).


> 1. if we enable schema versioning and forward migration, can we
>    tell ODB to also accept newer schemas (without migrating of
>    course) or will QDB simply refuse to cooperate

All ODB statements always explicitly list all the columns in SELECT-
lists, etc. In other words, we don't do "SELECT *". So, provided
the new schema is a proper superset (see above) of the old one,
the old code should theoretically work.


> 2. if 1. is true, would we be able to traverse polymorphic 
> relationships where new classes have been defined and are
> referenced in the relationship? Our expectation would be that
> non-mapped classes would simply be ignored.
>  
> example:
>  
> schema 1:   classA 1---N-> classB
>                      classB ---subclass--> classB1
>  
> schema 2:   classA 1---N-> classB
>                      classB ---subclass--> classB1
>                      classB ---subclass--> classB2
>  
> now, when I traverse the relationship a->b in the app based on
> schema1, and the relationship contains, say, {classB1, classB2},
> I would only see {classB1}

This is a good one. No, unfortunately, it won't work. What will
happen is schema1-based application will load the data from the
classB table. It will examine the type_id stored in the classB
table (root or the polymorphic hierarchy). It will see "classB1"
id for the first entry, which it knows about and will load fine.
For the second entry it will see "classB2" which it has no idea
about. So it will throw the odb::no_type_info exception.

The only way I can think of to make this work is to query the
relationship manually (i.e., with a query that returns odb::result)
and then, while iterating over the result, catch no_type_info and
skip over such unknown entries. You could probably even do this
inside a callback so that it works just like an ordinary
relationship.

Good luck.

Boris