Thanks, Robert.
We already figured how to list all conflicting docs in a DB with a view.
Getting the last conflicting revision will also allow me to get the
previous state before the conflict.
Appreciating your help.
Best,
Kiril.
------------------------------------------------------------------------
On 14.12.2019 г. 20:59, Robert Newson wrote:
> The algorithm for choosing the winner is a little complicated and not really
> helpful to you here, though I'll describe it at the end anyway.
>
> What matters is that couchdb and pouchdb retain both versions of your
> document. Your application semantics determine what should happen once a
> document has more than one edit branch. You can fetch the doc with
> ?conflicts=true to determine if there are alternatives, and then decide
> whether to merge those revisions, or delete the "winner" to promote the
> "loser", etc. There's lots of articles about conflict resolution and our docs
> site also talks about this.
>
> The winner is chosen roughly as follows;
>
> 1) The longest edit branch wins
> 2) Edit branches that end in a non-deleted revision win over ones that end
> with a deleted revision
> 3) If there are multiple branches after considering 1) and 2) the _rev values
> are sorted and the one on the end is chosen.
>
>> On 13 Dec 2019, at 23:58, Kiril Stankov <[email protected]> wrote:
>>
>> Hi, thanks for your reply.
>> Yes, looking at the Couch Fauxton side I found the conflicts.
>> Can anyone explain how the winner is selected?
>> Anyway to disable this feature, so the GET method returns the previous
>> revision of the doc, before the conflict happened?
>>
>>
>> On 12/12/19 10:18 PM, Robert Newson wrote:
>>> Overwrote, are you sure? Was there no other revision available?
>>>
>>> What should happen is that both versions of the document will be replicated
>>> to both sides, and one of them (the same one) will be chosen as the
>>> "winner". The other is always available until you delete it. Query with
>>> /dbname/docid?conflicts=true to see if you get a _conflicts member with the
>>> losing revision, then query with /dbname/docid?rev=X where X is the losing
>>> revision to confirm it's your "lost" update.
>>>
>>> B.
>>>
>>>> On 12 Dec 2019, at 12:03, Kiril Stankov <[email protected]> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have 1 local PouchDB and 1 remote CouchDB (cluster mode).
>>>> As I wanted to prepare for conflicts and also monitor for them I did the
>>>> following test:
>>>> - Pouch and Couch were in sync with few docs in the same DB.
>>>> - stopped the connection between Pouch and Couch on network level.
>>>> - modified a doc in Pouch
>>>> - modified the same doc on Couch
>>>> - restored connectivity
>>>> - Expected Behavior: conflict
>>>> - Observed behavior: Couch version of the doc overwrote the Pouch version.
>>>>
>>>> Read the documentation here:
>>>> https://pouchdb.com/guides/replication.html
>>>> and here
>>>> https://pouchdb.com/guides/conflicts.htm
>>>> <https://pouchdb.com/guides/conflicts.html>
>>>>
>>>> but it doesn't seem to discuss this case.
>>>>
>>>> What is the designed behavior?
>>>> Thanks in advance!
>>>>
>>>> Kiril.
