Possible bug in the moment of synchronization

[marjanoh2]

I test database synchronization with 50 tables. Synchronization interval 30 seconds. I noticed that the changes that are made at the time of synchronization (1 -3 seconds) do not register as changes and then do not synchronize.
I made two videos to better understand the situation.

https://drive.google.com/open?id=1Gb4e9qjVwm5yzu_kv_n1oAFSv24QTN0m

https://drive.google.com/open?id=1yZ7dP10c968cXyucr5tCteRTB4ti0ksX

This is the code I use

private async Task DbSync()

{

        SqlSyncProvider serverProvider = new SqlSyncProvider(db1.ServerConnectionString);
        SqlSyncProvider clientProvider = new SqlSyncProvider(db1.ClientConnectionString);

        string[] tables = new DbAccess().GetTablesForSync(db1.ServerConnectionString);

        SyncAgent agent = new SyncAgent(clientProvider, serverProvider, tables);

        var s = await agent.SynchronizeAsync();


        GlobalVariables.syncLog += $"Total Changes DO : {s.TotalChangesDownloaded}, UP : {s.TotalChangesUploaded }, conflicts : {s.TotalSyncConflicts  }, errors : {s.TotalSyncErrors   }, Start: {s.StartTime  } Duration : {s.CompleteTime - s.StartTime  } \n";

    }

[Mimetis]

Thanks for this feedback.
I can reproduce this behavior and the bug is identified.
When the sync is over, a timestamp is updated in the master database.
This Timestamp contains the end of the sync process, and the next rows will be selected based on this timestamp, so far.

To resolve it, I will introduce a breaking changes for the next version:
Instead of updating the master database with the end of sync timestamp, I will update the master database with the begin of sync timestamp and then I will add a new column showing the total duration for the sync.

Why I didn't use this technic before ?

Because I used this end of sync timestamp as a kind of checkpoint: If we have such timestamp, we are sure the sync was finished, with no errors.

In the next version, having two columns (begin / end of sync) will be a little be more tricky, but I think it will be enough to guarantee the sync involved is finished (or not) without (or with) errors.

I'm actually work on this new behavior, expect a new version, very soon. But since it's a breaking changes, you will need to re-implement your whole sync architecture.

Is it making sense ? Are you just testing (in this case, breaking changes are not an issue) ?

Sebastien

[marjanoh2]

The most important thing is accurate synchronization. Anything to do in order to achieve this is accepted. At the moment, I'm just testing different situations to ensure it works smoothly before I use it in production.

[marjanoh2]

Is there any progress?

[Mimetis]

Yep, i'm actually working on it :)

[Mimetis]

hey @marjanoh2
Can you make a test with the last version 0.2.1 ?
Be careful, I changed a lot of things in the architecture of the sync process. Even the sync_scope table has changed.
You will have to make a test on a new database (Unprovision everything to be sure)