[
https://issues.apache.org/jira/browse/COUCHDB-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901708#comment-13901708
]
Brian Mitchell commented on COUCHDB-2063:
-----------------------------------------
We could pick the winning revision but that does dig that hole a little deeper.
Maybe instead of true, you could provide the type of result like winning,
all_conflicts, and siblings.
> 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)
