You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Benoit Chesneau (JIRA)" <ji...@apache.org> on 2011/01/09 22:34:45 UTC
[jira] Created: (COUCHDB-1020) 202 status on "DELETE /db"
202 status on "DELETE /db"
--------------------------
Key: COUCHDB-1020
URL: https://issues.apache.org/jira/browse/COUCHDB-1020
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 DELETE :
[[[
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.
[jira] [Resolved] (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Lehnardt resolved COUCHDB-1020.
-----------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 1.2)
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Affects Versions: 1.2
> Reporter: Benoit Chesneau
> Priority: Minor
>
> 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 DELETE :
> [[[
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979419#action_12979419 ]
Robert Newson commented on COUCHDB-1020:
----------------------------------------
I was about to say what Paul said, but there's no point saying it twice.
+1 on closing as "won't fix".
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Paul Joseph Davis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979416#action_12979416 ]
Paul Joseph Davis commented on COUCHDB-1020:
--------------------------------------------
Though, there's also this bit from the section on DELETE [1]:
> However, the server SHOULD NOT indicate success unless, at the time the response is
> given, it intends to delete the resource or move it to an inaccessible location.
which describes simply moving the file as a successful response.
In terms of the HTTP API, a call to DELETE is successful and enacted because the resource that was mentioned in the request is no longer accessible. IMO, the fact that the internal implementation does not delete the actual file until sometime in the future is of no consequence when discussing the externally visible HTTP API.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979418#action_12979418 ]
Jan Lehnardt commented on COUCHDB-1020:
---------------------------------------
What Paul said.
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Benoit Chesneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979426#action_12979426 ]
Benoit Chesneau commented on COUCHDB-1020:
------------------------------------------
afaik I think lotus domino has pending delete database feature. Until file isn't deleted it is pending. I reckon it works differently. You mark a file to be deleted than check it to finally delete file.
My idea is to consider a DB /delete as a way to mark the db as deleted (reference is removed) but saying file deletion is pending which could be considered as a 202 status response on delete. I can live with a 200, but this detail may be interesting for reporting and monitoring.
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979422#action_12979422 ]
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 DELETE;
"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: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.
[jira] Commented: (COUCHDB-1020) 202 status on "DELETE /db"
Posted by "Benoit Chesneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979421#action_12979421 ]
Benoit Chesneau commented on COUCHDB-1020:
------------------------------------------
202 is a successful response though. I understand your point anyway. Sending 202 is more for Quality reporting than anything.
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> 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 DELETE :
> [[[
> 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.