Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetching remote changes before resolving dirty state #152

Closed
atsepkov opened this issue Aug 26, 2016 · 1 comment
Closed

Fetching remote changes before resolving dirty state #152

atsepkov opened this issue Aug 26, 2016 · 1 comment
Labels

Comments

@atsepkov
Copy link

@atsepkov atsepkov commented Aug 26, 2016

In your README, you mention that dirty local changes must be sent to server first (https://github.com/nilbus/Backbone.dualStorage#data-synchronization), before new content from the server is fetched. For my use case, I'd need the opposite effect, can that be achieved?

Basically I've set up a work area that multiple users can access. When the user goes offline, he's welcome to continue working in the area, but is notified that his changes could create conflicts with other users. When the user's connection is restored, I need the local client to detect if user's changes can be applied cleanly or if the online room has diverged in the meantime. In the event it has diverged, the user could choose which changes to discard and which to merge, very similar to git's merge mechanism.

However, to accomplish this, I need to fetch the server state first, before applying user changes.

@nilbus nilbus added the Question label Aug 27, 2016
@nilbus
Copy link
Owner

@nilbus nilbus commented Aug 27, 2016

No, there's nothing built in for that mode of operation.

You might consider creating a new API endpoint (with a model that does not use dualstorage) that returns either a hash representing the room content or the room's last updated timestamp. When connectivity is restored or before pushing, ensure the room hasn't changed since its last known state. If it has, assume or check for conflict.

@nilbus nilbus closed this Aug 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.