Possible bug in the moment of synchronization

[mimetis]

Possible bug in the moment of synchronization

[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.

[Mimetis]

Yep, i'm actually working on it :)

[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]

Is there any progress?

[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)