couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Date Sun, 09 Jan 2011 22:38:45 GMT


Robert Newson commented on COUCHDB-1020:

202 is not a valid response code for the state that the server is in after a successful db

"10.2.3 The request has been accepted for processing, but the processing has not been completed."

The processing of the request "to DELETE /db" *has* been completed.

That there is ancillary work to clean up disk space is irrelevant. If you dispute that, find
me an RDBMS that makes the same guarantee as you are demanding for 200 when executing a "DROP
FROM" statement. No RDBMS ensures the matching rows are irretrievably expunged from disk in
that event and they also return a "Yes, this definitely succeeded" response not a "We did
what you asked but there's still some way to retrieve this information from disk so it's not
really, really dropped, you figure out what that means to you".

> 202 status on "DELETE /db"
> --------------------------
>                 Key: COUCHDB-1020
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: HTTP Interface
>    Affects Versions: 1.2
>            Reporter: Benoit Chesneau
>            Priority: Minor
>             Fix For: 1.2
> Current status is 200 . Following irc discussion there are 2 points of you considering
tthat sicne db isn't accessible from HTTP api, 200 is ok. 
> But still data is on the disk and effectively, deletion is asynchronous. HTTP Spec on
> [[[
> A successful response SHOULD be 200 (OK) if the response includes an entity describing
the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if
the action has been enacted but the response does not include an entity.
> ]]]
> and status 202 :
> [[[
> The request has been accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might be disallowed when processing
actually takes place. There is no facility for re-sending a status code from an asynchronous
operation such as this.
> The 202 response is intentionally non-committal. Its purpose is to allow a server to
accept a request for some other process (perhaps a batch-oriented process that is only run
once per day) without requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response SHOULD include an indication
of the request's current status and either a pointer to a status monitor or some estimate
of when the user can expect the request to be fulfilled.
> ]]]
> Since it's true that deletion introduce an aysnchronous process to delete the db file
an it's data, I think that 202 is more appropriate here.
> 202 would mean, that resource isn't available but deletion is running. Related to #COUCHDB-1019
we could pass a pid or taskid to the response eventually.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message