couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2063) Return current document with 409 response
Date Fri, 14 Feb 2014 12:08:19 GMT

    [ 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)

Mime
View raw message