On Jul 11, 2008, at 9:01 AM, Noah Slater wrote:
On Fri, Jul 11, 2008 at 09:20:41AM -0600, Michael Hendricks wrote:
Most database interface modules that I've worked with generate
exceptions in
such cases (even if the underlying database doesn't) as a way to
help the
programmer find his mistakes.
That is certainly not my experience.
Nor mine, it really is a concurrency issue, and concurrent deletes
should be acceptable
My other concern is that the CouchDB REST API doesn't accept double
deletions. It generates an error. If CouchDB is going to give an
error
in one place, I think it should be consistent and do it elsewhere
too.
Consistency is good.
Agreed, but remember the REST API is just an HTTP interface to
couchdb, and the norm with HTTP is to return an error if a url is not
found. Thus, when using the DELETE verb to a document url there
should be an error, if the url points to a missing resource. However,
when using the bulk_docs uri, you are using the verb POST to send a
payload of multiple transactions, which inherently falls outside of my
understanding of REST, which is all about a single URI pointing to a
single resource and using the HTTP verbs. So we should think of
consistency in the sense of how do we make the bulk_docs API look and
smell like taking several calls to the regular REST API and
implementing them as a single transaction.
In a previous post, I mentioned that I would eventually like to see
bulk_docs being able to process get, post, put, and delete verbs in a
single payload. With that in mind, I also think bulk_docs should not
be aggressive with HTTP error codes, and should instead include an
HTTP status code with each row of the response. It would then be up
to the app to parse the response and handle the status codes, and
would give couchdb a true multi/bulk-resource wrapper around the REST
API.
I can see some value in making this a configurable behavior if others
don't want an error under this circumstance. Of course, I probably
won't send a patch for that since it's not my itch ;-)
-1
Your absolutely right.
Configuration parameter proliferation is a Bad Thing.
--
Noah Slater, http://people.apache.org/~nslater/
