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).
> On 23 Oct 2019, at 11:16, Richard Ellis <ricel...@uk.ibm.com> wrote: > > Background: > https://docs.couchdb.org/en/2.3.1/api/database/common.html#api-doc-batch-writes > https://couchdb.slack.com/archives/CKSBJJ2MT/p1571749837010500 > >> ricellis 2:10 PM >> Anyone able to comment on whether batch=ok (batch mode writes) are still > going to be a thing in FDB based CouchDB? I didn't see it on the proposed > list of deprecations, but AIUI _ensure_full_commit is going to be a no-op > (even though the endpoint remains for replicator compatibility), so it > seems at least the option to manually flush a batch seems to be going. > >> jan 2:47 PM >> I don’t think we’ll keep that > >> rnewson 3:53 PM >> we should decide though, on dev mlist. >> I'd vote for 'recognise and ignore', same as for 'sorted=false' for > _view. > > Rounding out that discussion a couple of options were proposed in slack > for the handling of the batch=ok parameter in CouchDB 4/FDB: > > 1. Continue to accept the batch parameter, but ignore it and on success > return the 201 status code associated with the write's FDB commit. Note > this a slight change from the currently documented batch mode behaviour of > "The CouchDB server will respond with an HTTP 202 Accepted response code > immediately.". > > 2. No longer accept the batch parameter and return a 400 bad request if it > is used. > > Opening the discussion here about these two or any other options people > would like to propose. > > Rich > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >
