Sync & reset DB for migrations

[KrisLau]

In the Migrations doc, it states:

When you're not using migrations, the database will reset (delete all its contents) whenever you change the schema version.

I would like to utilize this to circumvent having to implement migrations and just version my API. However in order to do so, I would need to be able to:

• run a sync prior to the database reset
  • to prevent data loss if the user was offline, closed the app, went back online & updated their app (causing a schemaVersion change while there is still unsynced data)
• reset WatermelonDB
• re-sync

Is there a way I can do this?

It would be nice if we could maybe override migrations with an event handler like onSchemaVersionChange which would just allow me to have full control over the process or maybe have a migration step where I can put toVersion: * to handle all migrations and add reset and/or sync as a migration step

[Darhagonable]

I'd like this as well. Would be nice to have the backend handle the migrations since watermelondb migrations are quite limited and requires more manual work.

[KrisLau]

@radex Any way I can do this with the current implementation of WatermelonDB? I tried testing by changing the schemaVersion and just starting up the app but it wiped the database without synching again

[primus11]

I don't believe this would be trivial. Sync is using current (latest) definition for doing sync and migration is supposed to actually move database in that state so that sync can even happen.

Example

Version: 1
table cars { car_title: string }

Migration 1 -> 2
rename cars -> vehicles
rename vehicles.car_title -> vehicles.vehicle_title

Version: 2
table vehicles { vehicle_title: string }

When we are at schema version 2, sync only knows version 2 (doesn't know anything about cars or cars.car_title).

Technically you do have all data in db (collections + raw) but logic/details might have already changed. Instead of migrations one could version sync (so if version x sync as x or y otherwise) but it is debatable if it is not just easier to do migrations in that case (since if I understood correctly in other post you migrate only backend).

Alternative might be to save full definition of everything on migration (or successful db init) and use that when syncing. Sync functionality in that case should probably lose all generic types and be separated from definition and this could potentially work for syncs that don't try to do anything smart (some computation, merging, ... since otherwise you just hit the same wall sooner or later)

[KrisLau]

@primus11 That makes sense but tbh I would be ok with straight up just wiping the entire db clean > having the db recreate itself with the new schema > sync also which would probably simplify things. I just need the db to basically allow for the user to access the information/data offline without doing any writes to it

[primus11]

I know you mentioned offline but do you have a way to push more often? (there is PR lying around that does only push without pull)

Otherwise if this is a big pain point maybe consider keeping previous version until fully synced - it might be possible to force use of cached version via service worker

[KrisLau]

@primus11 Sorry i think maybe I'm not explaining well haha my app hasn't been published yet so i'm not having any issues in an existing app. I just felt like having the ability to change the schema without migration steps would be useful in reducing the amount of code needed to be maintained between versions esp if the app is not doing any writes while offline.