Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Fri, 14 Feb 2014 18:02:20 +0000 (UTC)
From: "Brian Mitchell (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12695119.1392338821679.44732.1392400940766@arcas>
In-Reply-To: <JIRA.12695119.1392338821679@arcas>
References: <JIRA.12695119.1392338821679@arcas>
Subject: [jira] [Commented] (COUCHDB-2063) Return current document with 409
 response
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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