You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Kiril Stankov <ki...@open-net.biz> on 2019/12/12 12:03:50 UTC
Expected behavior on conflict between PouchDB and CouchDB
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.
Re: Expected behavior on conflict between PouchDB and CouchDB
Posted by Kiril Stankov <ki...@open-net.biz>.
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 <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
Re: Expected behavior on conflict between PouchDB and CouchDB
Posted by Robert Newson <rn...@apache.org>.
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 <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
>
Re: Expected behavior on conflict between PouchDB and CouchDB
Posted by Kiril Stankov <ki...@open-net.biz>.
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 <ki...@open-net.biz> 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.
Re: Expected behavior on conflict between PouchDB and CouchDB
Posted by Robert Newson <rn...@apache.org>.
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 <ki...@open-net.biz> 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.