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.
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
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
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
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.
-
