[odb-users] Schema evolution and upward compatibility

Christian Sell christian at gsvitec.com
Wed Sep 16 12:23:47 EDT 2015


ok, thanks for the reply. So I take it that if my application contains a
 
#pragma db model version(1, 1)
 
and then encounters a model with, say, version (2, 2), ODB will not call exit()
on my application.
 
The rest of your answer is as expected. I really don't like this requirement
myself, but wasn't able to talk them out of it..
 
thanks,
Chris

> Boris Kolpackov <boris at codesynthesis.com> hat am 16. September 2015 um 17:59
> geschrieben:
>
>
> 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
Christian Sell

GS Vitec GmbH
Im Ziegelhaus 6-8
D-63571 Gelnhausen

mail: christian at gsvitec.com
mobil: +49 (0) 173 5384289

Tel: +49 (0) 6051 601.26-90
Fax: +49 (0) 6051 601.26-91


More information about the odb-users mailing list