Hi
I was wondering if anyone has any ideas on how I can do the following.
I require the ability to make changes to a document locally without syncing those changes to the server but when the server makes changes to the document I need those to overwrite my local changes.
The use case is follows, I require a live call to the server to turn on certain behaviour, the server will then update the document with those flags, I must however make the changes locally aswell to account for the possible delay before the servers changes sync through.
I have attempted to add a push replication filter but this seems to only fulfil the first part of the requirement (i.e. stops my changes from syncing through) but this can lead to incorrect behaviour when the server makes changes as sometimes they will not overwrite my local changes depending on what the revision count is on the document it seems).
Thanks in advance for any assistance
It sort of sounds like what you want is a pull only replication with a custom conflict resolver. You could set the conflict resolver to always have the remote revision win, and it sounds like that will accomplish what you want.
You didn’t mention a platform so I will arbitrarily choose the C# documentation around this.
Apologies I am on android,
I did originally try something like that but I found the merge conflict resolver was not always called, I think it may have been when the local revision count was higher than the one for the document on the server but I was not certain. I assume it was because whatever changes happened where not considered a conflict and there was an automatic win in favour of the local document. Do you know what the logic is for when something is considered a merge conflict and the resolver will be called ?
But then again I tried that on a PUSH_AND_PULL replicator with a push filter in place so maybe that is what caused the behaviour.
My difficulty is I need other documents to be able to push aswell and just this one document to be pull only, is it possible to attach two replicators (one push and pull for most of my documents and the other pull only for the single document that is read only) to a single database ?
You can have as many replicators on a single database as you want, however there is a small problem that we are currently trying to correct but cannot do so in a non breaking way at the moment. The push and pull replicator, all else being equal, will share the same checkpoint ID and will cause a lot of churn because of it (they will keep invalidating each other’s checkpoints and cause each other to start over the process from the beginning, minus pulling the actual documents).
However, you could probably have a push replicator with a filter to reject the one document you don’t want to push, and then a separate pull with the docIDs set to just that one document ID. Those are different enough that they will not use the same checkpoint ID. This scenario will become a bit easier in the next 3.1 release with collection support because then you could just put the one document you want to deal with separately into a different collection and you have the ability to make replicators per collection.
As for when a conflict happens, a conflict is defined as two revisions that do not share a linear history. You can visualize it as a git branch, whereby the tip of each branch is a revision. That is what a conflict is. So if you receive a revision from the remote side that has an ancestor that is older than the current local revision, that is a conflict (unless that particular revision already exists on the local side) and will be handled by the conflict resolver set for the replicator (via the replicator configuration).
Thank you for the detailed response I will try play around