Thanks for the explanation.
I concur, I prefer compatibility, but as I'm not coding it, I'll defer the
decision to others.
Jonathan
On Sep 1, 2020, 10:30 PM, at 10:30 PM, Paul Davis <paul.joseph.da...@gmail.com>
wrote:
>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
