My main question was actually related with that fact. I was wondering if I could either relay on couchdb to keep track of deleted documents until compacted or on the other hand use a flag in my documents to decide what if the should be shown or not in my client code.
>From my point of view (and needs) relaying in the fact that the document will not be deleted until the db is compated is not a mayor tread off but I believe that using a flag would be a more secure way. Relaying on couchdb would be making my code dependant of an implementation detail of the db. Thanks a lot for your help. > I just discovered yesterday that there is a backdoor to let you view > the deleted document, but only if you know it's revision: > > GET /dbname/id_of_deleted_doument?rev=1-90394320932 > > Perhaps this is a backdoor we just forgot to close. On the other > hand, I think it would be nice to allow non-guaranteed "reverts" of > accidentally deleted documents. 99% of the time, an immediate revert > of a delete would work just fine. I think I'd also be in favor of > making it possible to view the deleted document content without > knowing its revision beforehand; e.g. something like > > GET /dbname/id_of_deleted_document?deleted=true > > Best, Adam > > On Oct 27, 2009, at 10:36 AM, Alex P wrote: > >> deleted docs are present in the data file until a compaction occurs. >> that >> said, i don't know if there's a way to access one, but even if there >> were, >> it would be a non-deterministic operation. it's success would depend >> on >> whether a compact was performed. >> >> On Tue, Oct 27, 2009 at 5:24 AM, <[email protected]> wrote: >> >>> Hello there, >>> >>> I'm writting a piece of code in which i would like to be able to >>> retrieve >>> documents that have already been deleted by the user. I was >>> wondering if >>> that is possible or in the other hand the document is completely >>> deleted. >>> >>> Thanks for any help, >>> >>> Manuel >>> >>> > >
