Skip to content
This repository has been archived by the owner on Oct 6, 2020. It is now read-only.

Sync Conflict Management also during local use #141

Open
tickellsthrush opened this issue Apr 3, 2020 · 2 comments
Open

Sync Conflict Management also during local use #141

tickellsthrush opened this issue Apr 3, 2020 · 2 comments
Labels

Comments

@tickellsthrush
Copy link

Hi,

while using integrated cloud sync, "sync conflicts in case multiple user are using the same database" are detected and handled.
As a suggestion and enhancement for future versions, it would be nice to see this "Sync Conflict Management" also for local use. Even to lock the data.db for write access during an open session would be very helpful.

Background of this suggestion is the integrated cloud sync in combination with slow uploads and a bigger data.db. Because a cloud sync (local -> remote) requires the upload of the whole data.db, a slow upload speed can cause timeout - sync fails.

Updating the data.db inplace (locally) would be a workaround, but requires at least locking during an open session.

@joshirio
Copy link
Collaborator

joshirio commented Apr 3, 2020

Hi, thanks for the multiple suggestions. I'll look into them with more attention when time permits.

Basically, when you enable cloud-sync Sympytum locks the session by updating only the metadata file, called sync.meta which is very small and should get synced quickly.

As soon as you open Symphytum, even without changes, this meta file is uploaded with a flag to signal that the session has been opened by a user, so that other clients receive a warning if they open their client.

I'm not sure I understand your concerns for this issue.

As a suggestion and enhancement for future versions, it would be nice to see this "Sync Conflict Management" also for local use

What do you mean by local use? Any example of a workflow where you would hit an issue with current cloud-sync?

Background of this suggestion is the integrated cloud sync in combination with slow uploads and a bigger data.db. Because a cloud sync (local -> remote) requires the upload of the whole data.db, a slow upload speed can cause timeout - sync fails.

Just to be clear, by local sync you mean the "generic sync folder" implementation? Because if you use Dropbox/MEGA that sync metadata file is uploaded right away once the app opens. Uploading a small text file (sync.meta) takes very little even on very slow connections.

@tickellsthrush
Copy link
Author

Thanks for your fast and detailed reply!
Maybe my description was a bit ambiguous. My use case is as follows:

I use symphytum with enabled cloud sync, to synchronize it with a remote directory (no Dropbox/MEGA, just a directory provided by a Samba share - which probably means "generic sync folder" [unfortunately can not change the symphytum GUI from german to english]).
Sometimes I am dependent on a slow network connection (upload speed <1Mbit/sec ) and a symphytum data.db of > 5MB of size. If I change something in symphytum, obviously a sync to the remote directory is required and e.g. automatically starts on closing symphytum. This constellation frequently leads to a very long-running sync process and sometimes sync abort due to a timeout.

With "local use" I mean using symphytum with disabled cloud sync. Currently, only with cloud sync enabled, a Sync Conflict Management (via the sync.meta file) is provided.
With cloud sync disabled, a concurrent access of multiple clients (to the same portable_data directory) is currently not blocked nor detected. Therefore, the database can get corrupted. With cloud sync enabled, this is situation prevented.

My suggestion addresses a similar functionality like the sync.meta file, but also when cloud sync is disabled in symphytum.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants