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.
