return_conflict=true ?
On Fri, Feb 14, 2014 at 1:08 PM, Robert Newson (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901369#comment-13901369 > ] > > Robert Newson commented on COUCHDB-2063: > ---------------------------------------- > > Optionally returning the current winning revision on a 409 makes sense, it > still allows the client to retry correctly (by re-applying their change in > the context of the new revision). It just saves a roundtrip. > > Returning only the _rev can only encourage blind overwriting, it gives you > the token you need to succeed on the next write but not the context you need > to resolve (or realise you shouldn't retry). > > For backwards compatibility reasons, and principle of least astonishment, I > think users will have to ask for this behavior with a query parameter > (?current_rev_on_conflict=true, suggestions welcome). > > >> Return current document with 409 response >> ----------------------------------------- >> >> Key: COUCHDB-2063 >> URL: https://issues.apache.org/jira/browse/COUCHDB-2063 >> Project: CouchDB >> Issue Type: Bug >> Security Level: public(Regular issues) >> Reporter: Isaac Z. Schlueter >> >> You do a PUT, and it doesn't have the current rev. >> So then you do a GET, to get the current rev. >> Then you re-try your PUT. >> Please make the second request unnecessary. Just send the current doc in >> the 409 response body, unless the user opts-out with a `?send_current=false` >> or something. >> There are almost no examples of cases where you'd do a PUT and *not* want to >> immediately GET the doc on a 409. The only case I could think of would be >> an in-place modifying follower where you don't care about a 409, because it >> means that another change is coming in the stream anyway. Are there any >> others? Even in those cases, you could just set the opt-out flag to not get >> the current data in the response. >> The only harm in doing this is that outdated apps will still do the >> (now-unnecessary) GET. That's not so bad. They'll keep working. >> Systems with a single write-master and multiple read-slaves, however, will >> be able to leverage this to great effect, rather than relying on >> cache-busting query params and other kludges. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160)
