You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Alexander Shorin (JIRA)" <ji...@apache.org> on 2014/02/14 10:47:19 UTC

[jira] [Commented] (COUCHDB-2063) Return current document with 409 response

    [ https://issues.apache.org/jira/browse/COUCHDB-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901276#comment-13901276 ] 

Alexander Shorin commented on COUCHDB-2063:
-------------------------------------------

I think this change leads to implicit behaviour and harmful usage of CouchDB API: you may actually use only PUT requests both for fetching and updating the documents.

I believe that PUT is not the request method where you expects large response body to handle: you documents could be very large. You may wanted to use HEAD method for fetching only current revision from ETag header.

However, current PUT behaviour for conflicts a bit violates RFC description for this status code:
{quote}
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
{quote}

CouchDB response body for conflicts isn't much informative about the source of the conflict:
{code}
{
    "error": "conflict", 
    "reason": "Document update conflict."
}
{code}

May be we should include current rev into response body? Like
{code}
{
    "error": "conflict", 
    "reason": "Document update conflict.",
    "source": {
        "rev": "8-cfb86fd4211a86e03d1203bdcbdf31f0"
    }
}
{code}

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