> On 23. Oct 2019, at 13:32, Arturo GARCIA-VARGAS <art...@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 <art...@ficuslabs.com>
>>> wrote:
>>>
>>> My opinion....
>>>
>>> On 23/10/2019 12:15, Jan Lehnardt wrote:
>>>>
>>>>> On 23. Oct 2019, at 12:40, Robert Samuel Newson <rnew...@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
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
