[odb-users] --suppress-migration issues

Boris Kolpackov boris at codesynthesis.com
Mon Apr 25 05:40:01 EDT 2016

Hi Steffen,

Steffen Groot <SGroot at lely.com> writes:

> We're using ODB on a sqlite database. I'd like to add an 
> on_delete(cascade) constraint to an existing data model. This is not 
> possible to migrate with sqlite, so ODB gives an error when running the 
> pre-compiler. So, in this case i'd like to do the migration myself and run 
> the compiler with the --suppress-migration option. However, I still get 
> the error, so I'm not able to generate the new model at all. Is this a 
> bug?
> I can work around the problem by doing it in 2 steps, but I guess the 
> --supress-migration option should just suppress the error?

The --suppress-migration option only suppresses the generation of schema
migration statements (SQL ALTER ...), it doesn't "suppress" schema migration
support itself (to do that you would just remove the model version pragma).

The recommended way to achieve this with schema migration is to create a
new table (with on_delete(cascade)) and then migrate the data. Here is an
example. Suppose this is your class at version 1:

// version 1
#pragma db object
class person

  string first;
  string last;

Now you want to add on_delete(cascade):

// version 2
#pragma db object table("person") deleted(2) // Map to the old table.
struct old_person
  string first;
  string last;

#pragma db object table("person2")
class person

  string first;
  string last;

The idea here is to create a (soft-deleted) "ghost" of an old class
(old_person) and use it to migrate the data to the new table. Section
13.4, "Soft Object Model Changes" has more details and an example.

> On a slightly related note, is it possible to access the 'create table' 
> statement that exists in the generated code? From the source I guess not, 
> but it would be usefull in my custom migration script.

Not in the generated code but you can generate them as a standalone SQL
file which you can then chop and slice as you please.

> (Since the alter table statement is so limited in sqlite, I want to do 
> rename table - create new table - migrate data - remove renamed table. 
> Would be also be a nice feature for ODB of course ;) )

Yes, maybe in the future. The concern is the complexity/reliability. Also,
hopefully, SQLite folks will improve their ALTER support in the next major


More information about the odb-users mailing list