Replication of deletions isn't affected due to the new_edits=false
flag like you guessed. This is purely "interactively creating a new
document that is deleted". Its a fairly minor edge case in that the
document must not exist. Any other attempt to "revive" a deleted doc
into a deleted state will fail with a conflict on 3.x.
I'm +0 for compatibility. Its not a significant amount of work to
implement the behavior and we can always deprecate it in the future to
remove the weird edge case of "document that has never existed can be
created in a deleted state".
On Tue, Sep 1, 2020 at 3:26 PM Jonathan Hall <fli...@flimzy.com> wrote:
>
> Isn't compatibility required to support replication of deleted documents? Or
> does creation of a deleted document work with new_edits=false?
>
>
>
> On Sep 1, 2020, 10:16 PM, at 10:16 PM, Nick Vatamaniuc <vatam...@apache.org>
> wrote:
> >Hi everyone,
> >
> >While running PouchDB replication unit tests against the CouchDB 4
> >replicator PR branch (thanks to Garren Smith, who helped set up the
> >tests), we had noticed a doc update API incompatibility between
> >CouchDB 3.x/PouchDB and the prototype/fdb-layer branch: CouchDB
> >3.x/PouchDB allow creating new deleted documents and
> >prototype/fdb-layer branch doesn't.
> >
> >For example:
> >
> >$ http put $DB1/mydb/doc1 _deleted:='true' a=b
> >HTTP/1.1 200 OK
> >
> >{
> > "id": "doc1",
> > "ok": true,
> > "rev": "1-ad7eb689fcae75e7a7edb57dc1f30939"
> >}
> >
> >$ http $DB1/mydb/doc1?deleted=true
> >HTTP/1.1 200 OK
> >
> >{
> > "_deleted": true,
> > "_id": "doc1",
> > "_rev": "1-ad7eb689fcae75e7a7edb57dc1f30939",
> > "a": "b"
> >}
> >
> >On prototype/fdb-layer it returns a 409 conflict error
> >
> >I opened a PR to make the prototype/fdb-layer branch behave the same
> >and keep the API compatibility, but also wanted to see what the
> >community thinks.
> >
> >https://github.com/apache/couchdb/pull/3123
> >
> >Would we want to keep compatibility with CouchDB 3.x/PouchDB or,
> >return a conflict (409), like the prototype/fdb-layer branch does?
> >
> >My vote is for compatibility.
> >
> >Thanks,
> >-Nick
