Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <DD5F00B6-C9D1-4D16-8101-6289C7FBF9D5@blit.com>
To: couchdb-user@incubator.apache.org
In-Reply-To: <20080711160105.GX15907@bytesexual.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: deleting a deleted document
Date: Fri, 11 Jul 2008 10:30:55 -0700
References: <20080710033453.GA4875@ginosko.ndrix.org>
 <20080710233513.GI5886@ginosko.ndrix.org>
 <ADEE44AB-3ED6-4E11-9264-2C6B22A20364@blit.com>
 <20080711152041.GA2423@ginosko.ndrix.org>
 <20080711160105.GX15907@bytesexual.org>
From: Troy Kruthoff <tkruthoff@blit.com>


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/