mqus

Hm. I think this stems from the issue that all migration steps are run within a transaction (to be able to roll them back if something fails) and changing this...

I was slightly mistaken. The reason for the issue is right, but the transaction is opened within sqflite and not in floor, so we can not fix this in floor.

> It is not possible to rename a column, remove a column, or add or remove constraints from a table. Where do you read this? The page you linked exactly...

Yes I understand the need. Your option for a workaround (2.) would be to do the migrations manually by creating `@Query`s with your actions(and the PRAGMA settings) and manually determining...

https://github.com/tekartik/sqflite/issues/624 and https://github.com/tekartik/sqflite/issues/297 have suggestions for solutions useable by floor, none perfect.

it will not work with 1, 2, 3, or even thousand migrations scripts because each and every one is executed within the same callback which only is executed within the...

We could improve the workaround by also adding `onConfigure` to the callbacks you can provide to floor. (Without editing the generated sources)

I don't think that we will release another 0.x update, we don't even have a branch for that. But I'm not managing the releases here ;)

You should be able to set it back to `ON` in the `onOpen` Callback. I added an example in the mentioned PR: https://github.com/vitusortner/floor/blob/bc1f945d086fc59f250d996d8c67e5e20ba73e1b/floor/test/integration/database_test.dart#L377-L386

the callback order is roughly: you call database.open() -> onConfigure -> (onCreate OR onUpgrade OR onDowngrade) -> onOpen ->you get your database instance. in onCreate, the generated schema is applied...