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.
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
