Followup: RxDB "Cannot open database state with newer RxDB version" error when trying to update from v13 to v15

[phal0r]

This is a followup to #5706, because it is closed already. I hope it is ok, to handle it like this.

According to https://rxdb.info/migration-storage.html and the last statement

There is no 13->15 migration. You can only migrate one version at a time.

I am still confused on how to rollout version updates to our app. Before we would just create a new migrationStrategy for the next version and older clients could just use the upgrade from their current version to the latest. If I understand the new approach correctly, this is not possible anymore.

Consider the very common scenario of native apps in the appstore (or just old serviceworkers in a browser). We cannot force every client to update and don't know, when they will use the app again or update to a newer version.

How can we create a path forward for all those people, that might update in the future, while we rolled out new versions in between. With the "old" approach they would just go through all missing migrations, with the new approach it is unclear how to tackle this.

[pubkey]

There are two things that need a migration.
One is when you change your schema. There you can use the migration strategy and increase the schema version.

The other thing is when you migrate between major RxDB versions. There you need a way to read out the old data and store it into the newest RxDB version. RxDB of course does not ship all code to do that between all possible RxDB versions. It only knows how to interact with the previous major RxDB version.

There is no "old" approach, there have always been these two ways of migration. Imagine you have stored data in a postgres version 2.0 database and now you want to update to postgres v14. You have to read out the old data and store it into the new database.

[phal0r]

Thanks for the explanation and I understand that. Seems, that we were just lucky in the past to not jump more than one major version. Also we added a migration step for a major version bump. Not sure, where we got this from. So I guess, this was useless.

So actually the only way to be sure, is, to use a different database name for each major version, right? (Given, that data can be loaded from the server).

Just in theory: What if we wanted to support migrating local data? Is there a function to detect the major version of a database? In this case, we could dynamically import an older rxdb version.

[pubkey]

So I guess, this was useless.

No, in the past often a migration could be done by just running the schema-migration. This is not always possible.

So actually the only way to be sure, is, to use a different database name for each major version, right?
Yes

What if we wanted to support migrating local data? Is there a function to detect the major version of a database?

The migration is idempotent and it will automatcially detect if it was finished already. The version of rxdb is store somewhere in the internal store.

[phal0r]

No, in the past often a migration could be done by just running the schema-migration. This is not always possible.

Ok, this answers, why it worked before. Thanks!

The migration is idempotent and it will automatcially detect if it was finished already. The version of rxdb is store somewhere in the internal store.

My point was more on how to establish a stable upgrade path, if a client missed intermediate updates, i.e. installed the app when rxdb 13 was bundled. Didn't use the app for a longer time and now receives an update, which includes rxdb 15. So we need to detect in which version the current db is and how we can update it to the current version, since the migrate tool only works for the last major version (in this example rxdb 14). We could async load the required rxdb version (in this example rxdb14) to use the migrate tool to migrate from 13 -> 14 and then the migrate tool for 14 -> 15.

If we need to do this on our own, first we need to determine which version the client has and load the required libraries. This was the reason for my question.

[pubkey]

Yes you are right. You need both old versions in that case to do a stable migration from 13->14->15 and you would also need a way to determine which version the client has stored the data with.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. If you still have a problem, make a PR with a test case or to prove that you have tried to fix the problem. Notice that only bugs in the rxdb premium plugins are ensured to be fixed by the maintainer. Everything else is expected to be fixed by the community, likely you must fix it by yourself.

[phal0r]

If we want to tackle this, I will create a new issue. Currently we solve this by renaming the database on a new major version update.

[pubkey]

@phal0r I think I might have missunderstood your problem.
When you do a migration between sotrages or major RxDB versions, you MUST use a different database name.
This is intentional and also in the docs: https://rxdb.info/migration-storage.html#migrate-from-a-previous-rxdb-major-version