You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by ma...@themacaque.com on 2009/10/27 11:24:25 UTC
Where do deleceted docs go
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
Re: Where do deleceted docs go
Posted by Paul Davis <pa...@gmail.com>.
Specifying a revision to get older copies of a document has been
around since forever. There have been a couple discussions on removing
it to inform people that CouchDB rev's are not for version control,
but generally it hasn't overcome the "but how could I revert one
version back for undo?
On the other hand, perhaps just having an _undo handler that will
revert to a specific rev. Or possibly just force it to be the latest
revision (by posting the current revision, simple!).
Either, way, it was on purpose, but the status of whether it continues
to exist in the current form isn't something I'd bet the farm on.
Maybe beers though.
Paul Davis
On Tue, Oct 27, 2009 at 10:49 AM, Adam Kocoloski <ko...@apache.org> wrote:
> 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, <ma...@themacaque.com> 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
>>>
>>>
>
>
Re: Where do deleceted docs go
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Mandel,
On 28 Oct 2009, at 08:20, mandel@themacaque.com wrote:
> 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.
Do not rely on documents being around after you deleted them.
Cheers
Jan
--
>
>
> 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, <ma...@themacaque.com> 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
>>>>
>>>>
>>
>>
>
>
Re: Where do deleceted docs go
Posted by ma...@themacaque.com.
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, <ma...@themacaque.com> 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
>>>
>>>
>
>
Re: Where do deleceted docs go
Posted by Jan Lehnardt <ja...@apache.org>.
On 28 Oct 2009, at 13:29, Thomas Delaet wrote:
> If I understand this correctly, the fact that you can not rely on
> deleted documents being available cripples the synchronization
> mechanism.
>
> Situation:
>
> Node A
> => Document X (rev 1)
>
> Node B
> => Document X (rev 1)
>
> Events:
>
> 1. Node A deletes Document X
> 2. Node A compacts its database
> 3. Node B synchronizes its database with Node A
> => Node B will not know that document X is deleted.
This is wrong. Deletes replicate. Node B will know after replication
that node A had the document X deleted.
Cheers
Jan
--
> Alternatively: if Document X is at rev 2 on Node B, no conflict
> will be generated ...
>
> I guess that the ' GET /dbname/id_of_deleted_document?deleted=true'
> that you propose is needed, but doesn't the replication algorithm need
> to be adapted too?
>
> Kind Regards
>
> --Thomas
>
>
>
> On Tue, Oct 27, 2009 at 3:49 PM, Adam Kocoloski
> <ko...@apache.org> wrote:
>> 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, <ma...@themacaque.com> 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
>>>>
>>>>
>>
>>
>
Re: Where do deleceted docs go
Posted by Randall Leeds <ra...@gmail.com>.
Aaaannnd... grepping the source gets me the answer in about 30 seconds.
If my Erlang literacy serves me right, it looks like:
POST /db/_purge
with body: {'doc1': ['1-42793874', '2-2348759', ... ], 'doc2': ['8-12341',
'10-850234']}
Just tried it on my machine and it appears to work fine with 0.10.0.
The only thing that bothers me is that requesting a document with ?revs=true
returns a list of rev "ids" which are only the part of the rev after the
dash (eg '28a4512efc7' instead of '3-28a4512efc7') but in order to purge a
document you have to specify the full revision identifier with both parts.
?rev_info=true gives you access to this information, but why isn't it
returned with ?revs=true?
-Randall
On Wed, Oct 28, 2009 at 22:28, Randall Leeds <ra...@gmail.com>wrote:
> I don't see any purge api documented anywhere?
> Can someone explain how this works or where I can find info?
> As always, I'd gladly update the wiki.
>
> -Randall
>
>
> On Wed, Oct 28, 2009 at 05:42, Paul Davis <pa...@gmail.com>wrote:
>
>> On Wed, Oct 28, 2009 at 8:39 AM, Paul Davis <pa...@gmail.com>
>> wrote:
>> > On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org>
>> wrote:
>> >> If I understand this correctly, the fact that you can not rely on
>> >> deleted documents being available cripples the synchronization
>> >> mechanism.
>> >
>> > Compaction only removes the body of deleted documents. Revisions are
>> > kept around specifically for this reason.
>> >
>> > HTH,
>> > Paul Davis
>> >
>>
>> Also, on a side note, for people wanting the "remove this document in
>> such a matter that replication will *not* delete the document in the
>> target db" you want to use the purge API. This is generally *not* what
>> most people should use. Purge exists for things like rebalancing nodes
>> in a cluster. Effectively operations that want to 'reparent' a docid
>> to a different shard or some such.
>>
>> Paul Davis
>>
>
>
Re: Where do deleceted docs go
Posted by Randall Leeds <ra...@gmail.com>.
Aaaannnd... grepping the source gets me the answer in about 30 seconds.
If my Erlang literacy serves me right, it looks like:
POST /db/_purge
with body: {'doc1': ['1-42793874', '2-2348759', ... ], 'doc2': ['8-12341',
'10-850234']}
Just tried it on my machine and it appears to work fine with 0.10.0.
The only thing that bothers me is that requesting a document with ?revs=true
returns a list of rev "ids" which are only the part of the rev after the
dash (eg '28a4512efc7' instead of '3-28a4512efc7') but in order to purge a
document you have to specify the full revision identifier with both parts.
?rev_info=true gives you access to this information, but why isn't it
returned with ?revs=true?
-Randall
On Wed, Oct 28, 2009 at 22:28, Randall Leeds <ra...@gmail.com>wrote:
> I don't see any purge api documented anywhere?
> Can someone explain how this works or where I can find info?
> As always, I'd gladly update the wiki.
>
> -Randall
>
>
> On Wed, Oct 28, 2009 at 05:42, Paul Davis <pa...@gmail.com>wrote:
>
>> On Wed, Oct 28, 2009 at 8:39 AM, Paul Davis <pa...@gmail.com>
>> wrote:
>> > On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org>
>> wrote:
>> >> If I understand this correctly, the fact that you can not rely on
>> >> deleted documents being available cripples the synchronization
>> >> mechanism.
>> >
>> > Compaction only removes the body of deleted documents. Revisions are
>> > kept around specifically for this reason.
>> >
>> > HTH,
>> > Paul Davis
>> >
>>
>> Also, on a side note, for people wanting the "remove this document in
>> such a matter that replication will *not* delete the document in the
>> target db" you want to use the purge API. This is generally *not* what
>> most people should use. Purge exists for things like rebalancing nodes
>> in a cluster. Effectively operations that want to 'reparent' a docid
>> to a different shard or some such.
>>
>> Paul Davis
>>
>
>
Re: Where do deleceted docs go
Posted by Randall Leeds <ra...@gmail.com>.
I don't see any purge api documented anywhere?
Can someone explain how this works or where I can find info?
As always, I'd gladly update the wiki.
-Randall
On Wed, Oct 28, 2009 at 05:42, Paul Davis <pa...@gmail.com>wrote:
> On Wed, Oct 28, 2009 at 8:39 AM, Paul Davis <pa...@gmail.com>
> wrote:
> > On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org>
> wrote:
> >> If I understand this correctly, the fact that you can not rely on
> >> deleted documents being available cripples the synchronization
> >> mechanism.
> >
> > Compaction only removes the body of deleted documents. Revisions are
> > kept around specifically for this reason.
> >
> > HTH,
> > Paul Davis
> >
>
> Also, on a side note, for people wanting the "remove this document in
> such a matter that replication will *not* delete the document in the
> target db" you want to use the purge API. This is generally *not* what
> most people should use. Purge exists for things like rebalancing nodes
> in a cluster. Effectively operations that want to 'reparent' a docid
> to a different shard or some such.
>
> Paul Davis
>
Re: Where do deleceted docs go
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Oct 28, 2009 at 8:39 AM, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org> wrote:
>> If I understand this correctly, the fact that you can not rely on
>> deleted documents being available cripples the synchronization
>> mechanism.
>
> Compaction only removes the body of deleted documents. Revisions are
> kept around specifically for this reason.
>
> HTH,
> Paul Davis
>
Also, on a side note, for people wanting the "remove this document in
such a matter that replication will *not* delete the document in the
target db" you want to use the purge API. This is generally *not* what
most people should use. Purge exists for things like rebalancing nodes
in a cluster. Effectively operations that want to 'reparent' a docid
to a different shard or some such.
Paul Davis
Re: Where do deleceted docs go
Posted by Thomas Delaet <th...@delaet.org>.
Excellent. Thanks!
--Thomas
On Wed, Oct 28, 2009 at 1:39 PM, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org> wrote:
>> If I understand this correctly, the fact that you can not rely on
>> deleted documents being available cripples the synchronization
>> mechanism.
>
> Compaction only removes the body of deleted documents. Revisions are
> kept around specifically for this reason.
>
> HTH,
> Paul Davis
>
Re: Where do deleceted docs go
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet <th...@delaet.org> wrote:
> If I understand this correctly, the fact that you can not rely on
> deleted documents being available cripples the synchronization
> mechanism.
Compaction only removes the body of deleted documents. Revisions are
kept around specifically for this reason.
HTH,
Paul Davis
Re: Where do deleceted docs go
Posted by Jan Lehnardt <ja...@apache.org>.
On 28 Oct 2009, at 13:29, Thomas Delaet wrote:
> If I understand this correctly, the fact that you can not rely on
> deleted documents being available cripples the synchronization
> mechanism.
>
> Situation:
>
> Node A
> => Document X (rev 1)
>
> Node B
> => Document X (rev 1)
>
> Events:
>
> 1. Node A deletes Document X
> 2. Node A compacts its database
> 3. Node B synchronizes its database with Node A
> => Node B will not know that document X is deleted.
This is wrong. Deletes replicate. Node B will know after replication
that node A had the document X deleted.
Cheers
Jan
--
> Alternatively: if Document X is at rev 2 on Node B, no conflict
> will be generated ...
>
> I guess that the ' GET /dbname/id_of_deleted_document?deleted=true'
> that you propose is needed, but doesn't the replication algorithm need
> to be adapted too?
>
> Kind Regards
>
> --Thomas
>
>
>
> On Tue, Oct 27, 2009 at 3:49 PM, Adam Kocoloski
> <ko...@apache.org> wrote:
>> 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, <ma...@themacaque.com> 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
>>>>
>>>>
>>
>>
>
Re: Where do deleceted docs go
Posted by Thomas Delaet <th...@delaet.org>.
If I understand this correctly, the fact that you can not rely on
deleted documents being available cripples the synchronization
mechanism.
Situation:
Node A
=> Document X (rev 1)
Node B
=> Document X (rev 1)
Events:
1. Node A deletes Document X
2. Node A compacts its database
3. Node B synchronizes its database with Node A
=> Node B will not know that document X is deleted.
Alternatively: if Document X is at rev 2 on Node B, no conflict
will be generated ...
I guess that the ' GET /dbname/id_of_deleted_document?deleted=true'
that you propose is needed, but doesn't the replication algorithm need
to be adapted too?
Kind Regards
--Thomas
On Tue, Oct 27, 2009 at 3:49 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 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, <ma...@themacaque.com> 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
>>>
>>>
>
>
Re: Where do deleceted docs go
Posted by Thomas Delaet <th...@delaet.org>.
If I understand this correctly, the fact that you can not rely on
deleted documents being available cripples the synchronization
mechanism.
Situation:
Node A
=> Document X (rev 1)
Node B
=> Document X (rev 1)
Events:
1. Node A deletes Document X
2. Node A compacts its database
3. Node B synchronizes its database with Node A
=> Node B will not know that document X is deleted.
Alternatively: if Document X is at rev 2 on Node B, no conflict
will be generated ...
I guess that the ' GET /dbname/id_of_deleted_document?deleted=true'
that you propose is needed, but doesn't the replication algorithm need
to be adapted too?
Kind Regards
--Thomas
On Tue, Oct 27, 2009 at 3:49 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 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, <ma...@themacaque.com> 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
>>>
>>>
>
>
Re: Where do deleceted docs go
Posted by Adam Kocoloski <ko...@apache.org>.
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, <ma...@themacaque.com> 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
>>
>>
Re: Where do deleceted docs go
Posted by Adam Kocoloski <ko...@apache.org>.
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, <ma...@themacaque.com> 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
>>
>>
Re: Where do deleceted docs go
Posted by Alex P <ap...@kolosy.com>.
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, <ma...@themacaque.com> 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
>
>