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
