IssueTracker

*Room, not Realm haha

i'm still skeptical about changing the default to crash because I'm worried that some apps won't handle migrating from older versions properly.
But creating a builder option totally makes sense so that more avare developers can turn it on.
Btw, another nice thing about drop by default is the development time. during development, you can easily increment it and pass the check and then just provide the migration from latest release to current release when shipping the app.

If some apps won't handle migrating and it is convenient for them to drop user data, it should not become a problem for those who respect user data. Respecting user data is more important that convenience for *some* lazy devs who can't write JUST ONE LINE to drop tables.

Dropping a user data is not always a bad thing, even for offline first apps.
Usually, local modifications are stored in a separate queue that is independent from the data in the db (mostly because data might be overridden).
So even if the data is nuked, local modifications can be restored. It is a fair compromise. In the common case scenario, the device probably had enough time to run any pending jobs before the app is updated so it is rarely a case where app is updated but  it had local modifications. Even in that case, data is not lost since the modifications stay in a separate queue.

Worst case scenario of someone failing to write a migration and the app crash looping on the user's device is really bad. It is actually very easy to end up in that situation if the developer simply uninstalls the app to get around the migration because they were focused on solving another problem.

I think the best action for us is to add a "forceMigrations" method into the builder that will always enforce migrations. This way, more aware developers can turn it on (they are also more likely to read the docs).

There are two offline scenarios IMHO: one is a pure cache mode and you basically do not care about local data, but the other one is where a user generates some content offline. In that scenario it's essential that the data is never deleted. Assuming that all developers respect their user data it is still possible to make a mistake and having user data dropped can be an expensive mistake in that case.

What is the issue with having a default migration that will fix up the schema to have the correct tables + columns? E.g. not dropping tables or columns, just adding them and updating indices etc. That could still fail when the data does not match the constraints set, but at least it prevents data to be lost and sends a signal during development as opposed to silently dropping the whole schema.