0

Let me provide a scenario:

I have a document with _id: 'doc-123'. I delete it by calling db.put(doc) with _deleted: true.

On a separate device, I create 1 or more new revisions of doc-123, but I never delete that document.

When they sync and a conflict occurs, I need a guarantee that the _deleted: true revision will win.

By PouchDB (and perhaps CouchDB as well?) conflict resolution algorithms, if an eventual conflict does occur between this deleted document and a new revision(s) of that document (but not deleted), is it possible to guarantee that the deleted document revision will always be the winning one?

I want to ensure the case of a conflict does not result in document resurrection.

Is this behavior by default or do I need to write conflict resolution code for this case?

I read the PouchDB conflicts document and didn't see anything mentioning this.

aeharding
  • 486
  • 1
  • 4
  • 13

1 Answers1

1

Conflicts in CouchDB/PouchDB have to be resolved manually (as in the database won't do this for you. you can still automate it). Since you'll have to do this manually, you can choose any logic that satisfies your needs.

Kul
  • 1,239
  • 8
  • 18
  • Where would the best place to do something like this in Pouchdb be (on a global basis)? – aeharding Sep 14 '16 at 14:43
  • It could be periodic or it can be invoked manually (eg, from a menu) – Kul Sep 14 '16 at 14:50
  • Would the best way to do this be check for `_deleted_conflicts` and then add _deleted: true to the winning revision (and then delete the conflict revision)? – aeharding Sep 14 '16 at 15:16
  • Well, I found this question: https://stackoverflow.com/questions/13043927/resolving-replication-conflicts-for-deleted-documents-in-couchdb That guy seems to be doing the same thing I want to do: Prevent _deleted documents from being resurrected. It seems to be a tricky process requiring an additional property on the document. – aeharding Sep 14 '16 at 15:28
  • edit: was wrong info. The question you've linked to does what you want – Kul Sep 14 '16 at 15:29