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
2. Stop doing it because it is well..., deprecated. Update your client.
-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
