AzureMobileApps Client Database Compatibility.

[richard-einfinity]

One of the issues that I'm currently facing while moving from AzureMobileApps to the community toolkit is what to do with the existing database.

I can see that the question has previously been asked. #64 and I'm wondering how much of an issue this might really be.

While refactoring my current code base I have used a new database name so haven't really dealt with the previous database, it's still there on users devices if needed. If the client has synced successfully there is no issue, new database is created and the entities are synced back down. The problem is if there are pending operations and the client hasn't synced we might be losing data. Our app tries to sync when data is modified and periodically as a background task, if there is connectivity.

I currently have two ideas for dealing with this.

1. Migrations

The current database structure isn't a million miles away from the old structure. Delta tokens look the same and DataSyncOperation and Table operation aren't a million miles apart. If the users Offline Entities are compatible they should be able to be mapped straight onto the existing tables.

We could run into issues if the database already exists or not when mapping to the existing tables, may possibly need 2 sets of migrations which could get messy, especially if the models evolve over time. Entity configurations will need to be added to match the new entities to the existing tables for the initial migration. Then additional columns added and data fixed up for a subsequent migration.

A single set of migrations probably makes a lot of sense, in which case we could check if the tables exist and rename the user tables to avoid collision before applying the migrations. Apply the migrations. Copy and fixup the data into the new tables. Drop the old tables.

2. Query Old Operation Queue.

The operation queue should contain all the pending operations and a serialized copy of the entity. If the database already exists we could create a new database using the new format. Perform an initial sync. Query the TableOperation table for pending operations. Deserialize the entity and apply the changes against the new offline context. Push the changes. Delete the old database if successful

This could also be used with migrations but user tables will need to be dropped before applying the migrations. And then old system tables.

I'm going to have to tackle this shortly so happy to share the results.

[adrianhall]

Migration from Azure Mobile Apps is specifically something I have not covered. My suggestion would be:

1. Create a new database and synchronize down
2. If the old database exists, create a sqlitedatabase connection and explicitly query the old database to access the operations queue.
   a. For each entry that is pending, try to do the same change on the new EF Core based database. You'll have to pull the current value of the entity in the table and the operations queue (to see if it's add/delete/modify)
   b. Then push the EF Core operations so that the remote service gets updated.
   c. Finally, remove the old database (so that you don't carry on updating from the old database)

This allows an effective migration, but it's completely custom.

Looking forward to you writing about your experience!

[richard-einfinity]

Hi Adrian, I think this is where I got to as well. I was going to check the delta token to see if it was later in the new db and potential skip the operation. I’ll need to do this before my next deployment as I’ve got users already using the app. I’ll post up my results. Cheers Rich