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: <F5F0BF09-CAA1-432E-98C3-2A9AD939D857@apache.org>
From: Damien Katz <damien@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <20080711182346.GF2423@ginosko.ndrix.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: deleting a deleted document
Date: Fri, 11 Jul 2008 14:44:07 -0400
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>
 <20080711182346.GF2423@ginosko.ndrix.org>

There is actually a use case for re-deleting documents.

CouchDB deletions replicate around, just like regular documents.  
However, I realized i's often not be enough to record that the  
document was deleted, you might also want there to be meta information  
stored in the deletion record, like who deleted it, and when.

I think I'm the only one who knows this, but you can put information  
any information into deleted documents that you can have in normal  
documents. Right now itsnt not very useful, and really though, you'd  
only want meta information in these documents, information about the  
deletion (who,when,why), not application data. You can use this meta  
information for security purposes (i.e. is this replicated delete by  
this user allowed) or for purge information, such that documents  
deleted X months/days/hours ago are now purged from the database. (no  
purge functionality exists just yet, but you see my point)

Anyway, the fact that this meta information is useful on a deletion  
also means you might want to "re-delete" something that's already  
deleted, to change the meta information associated with the deleted  
document.

One thing I don't understand about your request though, I'm not sure  
how you'd delete documents without actually knowing they where already  
deleted. Since it is required to have the rev to delete, wouldn't you  
also have loaded the document information to get the rev?

-Damien

On Jul 11, 2008, at 2:23 PM, Michael Hendricks wrote:

> On Fri, Jul 11, 2008 at 05:01:05PM +0100, Noah Slater wrote:
>> On Fri, Jul 11, 2008 at 09:20:41AM -0600, Michael Hendricks wrote:
>>> 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.
>
> The use case I'm working with is something like this.  I have a  
> document
> that I want to delete.  If the document exists in the database
> everything is fine and the delete operation proceeds normally.  If the
> document has already been deleted from the database, my own  
> knowledge of
> the database's state was obviously wrong (or I wouldn't have tried to
> delete this document).  In some cases I don't care and in some cases I
> do.
>
> If CouchDB silently deletes documents that have already been  
> deleted, I
> have no way of finding that out because the return value from  
> _bulk_docs
> gives no hint.
>
> If, for example, I run "rm file-does-not-exist" at a bash shell it
> generates a warning and helpfully sets $? to 1.  If I don't care that
> the file was missing, I just ignore the return value.  If I do care, I
> can take appropriate action.  I hesitate to use an example from  
> RDBMSes
> (since we probably wouldn't be here if we cared much for them), but  
> when
> I perform a DELETE query I receive a count of the rows affected (at
> least in PostgreSQL, MySQL and SQLite).  If the count matters to me, I
> can use it.  If not, I can ignore it.
>
> Perhaps _bulk_docs could return something like:
>
>    {
>        "ok" : true,
>        "new_revs" : [
>            { "id" : "123edce", "rev" : "12345" },
>            { "id" : "ca32f29", "rev" : "55632", "already_deleted" :  
> true },
>        ],
>    }
>
> which would let consumers take action if they care.
>
> We can't assume that people will just use DELETE if they want this  
> kind
> of notice because that doesn't scale well to deleting many records or
> performing these deletions as part of an atomic operation.
>
> -- 
> Michael