couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arturo GARCIA-VARGAS <art...@ficuslabs.com>
Subject Re: Batch mode options for CouchDB 4.0
Date Wed, 23 Oct 2019 11:56:46 GMT
Maybe my point is not coming across correctly.

By reading the docs, a consumer would match *explicitly* to a 202 
response, to acknowledge success.

We better be consistent and either hard-break this behaviour, or behave 
as before, but not silently switch the behaviour, even more if the 
operation behind is a no-op.

Well, my opinion.

On 23/10/2019 12:50, Jan Lehnardt wrote:
> 
> 
>> On 23. Oct 2019, at 13:32, Arturo GARCIA-VARGAS <arturo@ficuslabs.com> wrote:
>>
>> Well, a consumer would be explicitly waiting the the accept response code like responseCode
=== '202' as a sign of "success".  We have silently broken the consumer.
>>
>> Granted a consumer should cater for a '201' response, but the docs explicitly say
you do not get a 201 when using batch=ok.
> 
> A consumer that can’t deal with different HTTP response codes already isn’t doing
HTTP correctly. They could already equally receive a 400, 401, 500 or any other variety or
responses, so I think we’re fine here.
> 
> 
>>
>> On 23/10/2019 12:29, Jan Lehnardt wrote:
>>>> On 23. Oct 2019, at 13:25, Arturo GARCIA-VARGAS <arturo@ficuslabs.com>
wrote:
>>>>
>>>> My opinion....
>>>>
>>>> On 23/10/2019 12:15, Jan Lehnardt wrote:
>>>>>
>>>>>> On 23. Oct 2019, at 12:40, Robert Samuel Newson <rnewson@apache.org>
wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Just confirming my position on this. We should treat a request with
batch=ok as if the setting was not there. That is, make the same durable commit as normal.
We should therefore send a 201 Created response code. We should continue to validate the batch
setting (it can be absent or it can be "ok" but every other value is a 400 Bad Request).
>>>>>
>>>> -1 from me, we should:
>>>> 1. Drop it and be consistent with the API.  Maybe warning of deprecation
in couchdb-3?
>>>> 2. Enable same behaviour as before (accepted) with a no-op and config file
parameter.
>>>>
>>>> But not modify the behaviour of the API
>>> Can you explain why?
>>> The proposed behaviour is no worse than what the option enables, and it ensures
that existing software continues to work without (much) change.
>>> API purity for the sake of it is not really a goal here.
>>> Best
>>> Jan
> 

Mime
View raw message