Return-Path: 
 <user-return-7171-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org>
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 89525 invoked from network); 28 Oct 2009 12:29:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 28 Oct 2009 12:29:30 -0000
Received: (qmail 26969 invoked by uid 500); 28 Oct 2009 12:29:29 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 26884 invoked by uid 500); 28 Oct 2009 12:29:29 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@couchdb.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@couchdb.apache.org>
List-Post: <mailto:user@couchdb.apache.org>
List-Id: <user.couchdb.apache.org>
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 26866 invoked by uid 99); 28 Oct 2009 12:29:29 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Oct 2009 12:29:29 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of tdelaet@gmail.com designates
 72.14.220.158 as permitted sender)
Received: from [72.14.220.158] (HELO fg-out-1718.google.com) (72.14.220.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Oct 2009 12:29:21 +0000
Received: by fg-out-1718.google.com with SMTP id e12so417871fga.5
        for <multiple recipients>; Wed, 28 Oct 2009 05:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:sender:reply-to:received
         :in-reply-to:references:date:x-google-sender-auth:message-id:subject
         :from:to:cc:content-type:content-transfer-encoding;
        bh=0D3D3xsF96Dw2CgjMMKtyqNOfASXduqmApySixROw7U=;
        b=JCJvs17KjaYl01IJXS9bQjeOJg8NO7LshO9tfPblKBV4rr5mZ7DuUU5JuM93U6glv0
         1z0p3BlcofV4shcDIGqTOKwGruBsLPHfJOvNrNs0xN9Zj+GdLgdMLTBXsYRVoih6c3ZJ
         tpMj06g0APog1mTnxWNjCE6jYfCmVuKSxqat4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:reply-to:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=QweBHIOjoJR+bzVNiZ2fdDlVDEMugD1hHkfzOzRKOZiWA/igqIlUgJ2NepQAobdepb
         ue+HkpzSyq3eeAMWxBcwlZSo20Y4/r6BchJH4ek0SYB0dp/zmNtBpG3BRhWcGQKvuOO7
         V70nHqCYDyThDs7ti+txdoCe2hLUI0kwIwpkQ=
MIME-Version: 1.0
Sender: tdelaet@gmail.com
Reply-To: thomas@delaet.org
Received: by 10.103.48.26 with SMTP id a26mr1584170muk.83.1256732940706; Wed,
	28 Oct 2009 05:29:00 -0700 (PDT)
In-Reply-To: <C18C91DD-A003-404F-8A8A-611776CBF744@apache.org>
References: <11513.194.29.98.144.1256639065.squirrel@themacaque.com>
	 <8098243e0910270736p5d16229bs58324a446bc4f570@mail.gmail.com>
	 <C18C91DD-A003-404F-8A8A-611776CBF744@apache.org>
Date: Wed, 28 Oct 2009 13:29:00 +0100
X-Google-Sender-Auth: ae864802ba81f9bf
Message-ID: <a8a10a0910280529p3c2a7c5awf8c3acb8bfd7053a@mail.gmail.com>
Subject: Re: Where do deleceted docs go
From: Thomas Delaet <thomas@delaet.org>
To: user@couchdb.apache.org
Cc: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.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
 =3D> Document X (rev 1)

Node B
 =3D> 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
     =3D> 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=3Dtrue'
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 <kocolosk@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=3D1-90394320932
>
> Perhaps this is a backdoor we just forgot to close. =A0On the other hand,=
 I
> think it would be nice to allow non-guaranteed "reverts" of accidentally
> deleted documents. =A099% of the time, an immediate revert of a delete wo=
uld
> work just fine. =A0I 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=3Dtrue
>
> 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. tha=
t
>> said, i don't know if there's a way to access one, but even if there wer=
e,
>> 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, <mandel@themacaque.com> wrote:
>>
>>> Hello there,
>>>
>>> I'm writting a piece of code in which i would like to be able to retrie=
ve
>>> documents that have already been deleted by the user. I was wondering i=
f
>>> that is possible or in the other hand the document is completely delete=
d.
>>>
>>> Thanks for any help,
>>>
>>> Manuel
>>>
>>>
>
>