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:18:21 +0000 (UTC)
From: "James Mutton (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12695119.1392338821679.44820.1392401901613@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=13901725#comment-13901725 ] 

James Mutton commented on COUCHDB-2063:
---------------------------------------

Perhaps then, given the current behavior, it is enough to indicate conflict: true in the document and let the user go-ahead and request the conflicts if their intention is to handle that case.  This would be in-line with current behavior of individual documents and would then be adjusted accordingly depending on the outcome of the other ticket Bob mentiones.  Also, it would be nice if we end up requiring a querystring to trigger this, that it be of a similar naming convention as others (switching back and forth from "return_*" to "include_*" contributes to confusion in the API design.  IMHO)

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