> On 23. Oct 2019, at 14:26, Arturo GARCIA-VARGAS <art...@ficuslabs.com> wrote:
>
> I guess the way I see it (and where I may be wrong) is that batch=ok will
> become a deprecated use of the API. And if we are to support a deprecated
> behaviour:
>
> 1. Behave as before because you are nice, via an explicit config enable; or
The point is, we would be behaving “better than before”
> 2. Stop doing it because it is well..., deprecated. Update your client.
…and we don’t want to break client software, when we don’t have to.
Best
Jan
—
>
> -A.
>
> Again my opinion :-)
>
> On 23/10/2019 13:19, Jan Lehnardt wrote:
>>> On 23. Oct 2019, at 13:56, Arturo GARCIA-VARGAS <art...@ficuslabs.com>
>>> wrote:
>>>
>>> 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.
>> I think I do understand your point, however, the nature of this API allows
>> us to argue for the best of both worlds: batch=ok today says that the client
>> is fine with letting CouchDB decide when to fully commit data. Depending on
>> the circumstances, that decision could be “immediately”, or it could be
>> “some time later”. The proposal here now suggests that we switch this to be
>> always “immediately”, but regardless of batch=ok being present or not, the
>> client doesn’t really care about that. So I don’t think there is a good
>> reason for suggesting a hard break.
>> Best
>> Jan
>> —
>>>
>>> Well, my opinion.
>>>
>>> On 23/10/2019 12:50, Jan Lehnardt wrote:
>>>>> 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/
