What would be the best practice to synchronize new tables or new columns in old proyects

[maxrodro]

Hello everyone, two days ago I discovered the great potential of Dotmin.Sync and I have been researching the existing documentation, which would be a good practice to make new versions of Xamarin as an example and update new tables or new columns.

Should it have a general Deprovision or Provision method to execute it every time a version has a new modification and it rebuilds the synchronization tables, SP, etc?

Anyone with a comment ... thank you very much

:-)

[VagueGit]

Good question @maxrodro. We are experimenting with migrating one of our apps from Realm Cloud to DMS. Realm handles migrations automagically. I think it would be great if DMS did the same.

One major downside though is that Realm migrations are additive only. This means objects/properties cannot be renamed or deprecated. I think DMS has the potential to be smarter than that.

[Mimetis]

Hey @maxrodro

Actually you have a DeprovisionAsync() and a ProvisionAsync() methods.

If you look the documentation, you will see that it's not really complicated to use them : https://dotmimsync.readthedocs.io/Provision.html#provision-deprovision

The only thing to remember when using these methods is to save the scope tables at the end, depending your needs.
(I'm thinking about simplifying this step and encapsulate the save scope in the methods, but for now, you have to do it manually)

You have a sample here : https://github.com/Mimetis/Dotmim.Sync/tree/master/Samples/ProvisionDeprovision

Do you need more ?

[Mimetis]

I need to test it, before going further.
Maybe next week.
Do you have access to the client mobile application (be able to change the code ?. )

[maxrodro]

I apreciate it!!! @Mimetis

I have all the client code in Xamarin, I can make any changes.

[maxrodro]

Hi @Mimetis

Have you been able to review my case?

[Mimetis]

Well, I guess the problem here is that you don't have the column names in the SyncSetup object, since you are syncing all the columns (and that's perfectly fine)

As a workaround, here is my try. I'm currently working on the Customer table, where I've added a single column:

On the server, I assume you are making the ALTER COLUMN on your table, before running this:

var syncSetup = new SyncSetup(tables);
var progress = new SynchronousProgress<ProgressArgs>(s => Console.WriteLine($"{s.Source}:\t{s.Message}"));
var orchestrator = new RemoteOrchestrator(serverProvider, new SyncOptions(), syncSetup);

await orchestrator.DeprovisionAsync(SyncProvision.StoredProcedures | SyncProvision.Triggers, progress: progress);
await orchestrator.ProvisionAsync(SyncProvision.StoredProcedures | SyncProvision.Triggers, progress: progress);

Ok, really simple, just deprovisioning the stuff that can be impacted by columns (StoredProcedures and Triggers)
We don't need to deprovision the tracking tables since they are not impacted by the columns (only primary keys)
We don't need to deprovision the tables themselves, for ... obvious reasons :D

On the client, it's a little bit more complicated, but not that much, I guess.

If you don't want to make a full reinitialization, I guess you can do something like this. Once again, I'm assuming you are doing the ALTER COLUMN on the client table, before running this:

// Fake setup to deprovision one table only
var setup = new SyncSetup(new string[] { "Customer" });

// Creating a local orchestrator with this fake setup
var localOrchestrator = new LocalOrchestrator(clientProvider, clientOptions, setup);

// Deprovision all stored procedures and triggers for the table from the fake setup
await localOrchestrator.DeprovisionAsync(SyncProvision.StoredProcedures | SyncProvision.Triggers);

// Now, getting the full schema from server
var remoteOrchestrator = new WebClientOrchestrator(serviceUri);
var serverFullSchema = await remoteOrchestrator.GetSchemaAsync().ConfigureAwait(false);

// Provision again the local client.
// Since only Customer has been deprovisioned, the only provision will occure on this table
await agent.LocalOrchestrator.ProvisionAsync(serverFullSchema).ConfigureAwait(false);

Obviously if you don't want to make the ALTER TABLE by yourself, you can delete the local SQLITE database and make a full sync again.

Can you test it and give me feedback ?

[maxrodro]

Hi @Mimetis
Thank you very much, I am going to do the test in our environments, I appreciate your answer.