I think we came to a consensus to maintain compatibility. Thank you
all who participated in the discussion
Cheers,
-Nick
On Tue, Sep 1, 2020 at 4:40 PM Joan Touzet <woh...@apache.org> wrote:
>
> Same - keep for now, choose to deprecate later.
>
> Remember by our semver policy this would mean the earliest this endpoint
> could be removed would be CouchDB 5.0 (!)
>
> -Joan "time keeps on slippin', slippin'..." Touzet
>
> On 2020-09-01 4:35 p.m., Jonathan Hall wrote:
> > 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
> >
