Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
…328) For #327 Approach Instead of sending to the server the eldest `lastSyncAt` at Collector's end and updating the `lastSyncAt` of all the entries at the end of the `sync`, it now just sends the newest `lastSyncAt` which falls more natural (no need of modifying the `lastSyncAt` of any other entries at the end). In layman's terms it's asking: "Ok server, can you please bring me all the records that have been created or updated since the last time I synced with you?", where the last time is determined by the last entry that has been fetched (last entry has the most recent `lastSyncAt` value because they come sorted by `updated_at` in `ASCENDING` order from the server). This allows the syncing to be interrupted and resumed without any problem as it doesn't depend on any event on completion such as updating `lastSyncAt` for all entries at the end of the `sync` process. Avoiding pitfalls on upload What happens if other entries or updates are submitted to the server by other collectors while the current one is uploading their own changes? Will the current collector miss those changes? No, that's not a problem. In order to cover that scenario, `lastSyncAt` of each entry that is being `uploaded` on `remoteUpload` or `remoteUploadUpdate` is set to the newest `lastSyncAt` in the database at that moment. This allows capturing the new entries or updates that could have been uploaded to the server by other collectors while the current one was uploading their own changes.
- Loading branch information