Keep current database version when migration fails about floor

[mqus]

I'm currently triaging all the old issues.

Is this bug about:

1. We keep the old version even if we shouldn't or
2. We will fail in a big way but should keep the old database instead?

The description is not quite clear about this 😉
If you mean 1., what should be done to fix this?
If you mean 2., then to be honest I don't see how this would work, as the migration simply updates the database to match with the compiled entities, DAOs and other integrations. Keeping the old database simply will throw errors when updating/querying entities and not solve any problem.

[vitusortner]

Fair points. I was under the impression that when a migration e.g. from version 1 to 2 fails, version 2 will still be the new database version. This means that no data has been migrated but the new version is used already.

Solutions:

• provide the possibility of validating manual migrations earlier 👎
• make Floor generate migrations 🚀

If Floor would be able to generate migrations the chances would be smaller that these fail. What are your thoughts on this? @mqus

[mqus]

I think generating migrations is pretty impossible to get right... But I haven't worked with many ORMs yet[1] to have a good impression on how others do this. Why do I think it is impossible then? The following has to happen in migrations:

• adding/removing/changing columns
• adding/removing tables with constraints (indices/relations to other tables)

All of the above are very semantic operations which heavily depend on the application logic. I also think that they cannot be described more concise than in sql.

I think that failing early and loud is the right way, although i'm currently not near a pc to look at the code and what would be possible.

[1]The one that immediately comes to my mind is diesel in rust, in which the migrations are the only sql you will have to write. The fully-migrated database is then type-validated with the annotated entities. But that's a completely different orm concept.

[mqus]

After looking at the code it doesn't seem impossible to fail when we need to. I would also automatically put each migration into a Transaction that gets rolled back if anything fails. This would need Migration.migrate to accept a Transaction instead of a Database, which should be a painless substitution in many cases.
Regarding the integer value of the version field, I think this can be set manually and we should probably do this after each successful migration ourselves.

[vitusortner]

Sounds reasonable 👍