You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by fana <fa...@2flub.org> on 2010/01/03 12:31:31 UTC
Re: Questions on replication (how to prevent DELETEs and resync deleted
documents)
Hi,
I tried your method and it works.
The problem is, that I can undelete a document
but the data it carried is gone.
It seems this is normal behavior:
"The doc itself is gone, the deleted stub is still there for
replication conflict resolution."
http://mail-archives.apache.org/mod_mbox/couchdb-user/200901.mbox/%3C953A38F3-E1AA-4952-BEBA-B6FCECC69D72@apache.org%3E
So you can't really resurrect a deleted document with its data
or is there some other way?
On Sun, 27 Dec 2009 09:17:53 -0800, Troy Kruthoff <tk...@gmail.com>
wrote:
> I believe the revision does change when you delete the doc, meaning
> the delete will be replicated to your "master" for which you can
> monitor changes and un-delete the document, causing it's rev to again
> be modified and re-replicated to the slaves.
>
> Troy
Re: Questions on replication (how to prevent DELETEs and resync
deleted documents)
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 7:16 AM, fana <fa...@2flub.org> wrote:
>
> Ok, I think I figured it out now.
>
> I always used the revision ID which I saw in _changes
> to re-load a document and saving it again.
>
> If I use the previous revision ID (before deleting) to re-load
> the document, then the data is still there
> and I can save the document back.
>
> But for saving I used the revision ID
> which was generated by deleting the document.
>
> From my understanding this means, if you want to resurrect deleted
> documents,
> you have to do it before compaction happens.
>
> So, are the following steps the right approach for un-deleting documents? :
>
> 1) Don't run compaction
> until you un-deleted all the documents you want
>
> 2) Re-load a deleted document with a revision ID
> previous to the delete to get back the data
> and not only the stub of the document
>
> 3) Save it back but use the latest revision ID
> (the one you got after deleting the document)
exactly. but if you have a validation function that prevents deletes,
you shouldn't have anything to undelete.
>
> On Sun, 03 Jan 2010 12:31:31 +0100, fana <fa...@2flub.org> wrote:
>> Hi,
>>
>> I tried your method and it works.
>>
>> The problem is, that I can undelete a document
>> but the data it carried is gone.
>>
>> It seems this is normal behavior:
>>
>> "The doc itself is gone, the deleted stub is still there for
>> replication conflict resolution."
>>
>>
> http://mail-archives.apache.org/mod_mbox/couchdb-user/200901.mbox/%3C953A38F3-E1AA-4952-BEBA-B6FCECC69D72@apache.org%3E
>>
>> So you can't really resurrect a deleted document with its data
>> or is there some other way?
>>
>> On Sun, 27 Dec 2009 09:17:53 -0800, Troy Kruthoff <tk...@gmail.com>
>> wrote:
>>> I believe the revision does change when you delete the doc, meaning
>>> the delete will be replicated to your "master" for which you can
>>> monitor changes and un-delete the document, causing it's rev to again
>>> be modified and re-replicated to the slaves.
>>>
>>> Troy
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Questions on replication (how to prevent DELETEs and resync deleted
documents)
Posted by fana <fa...@2flub.org>.
Ok, I think I figured it out now.
I always used the revision ID which I saw in _changes
to re-load a document and saving it again.
If I use the previous revision ID (before deleting) to re-load
the document, then the data is still there
and I can save the document back.
But for saving I used the revision ID
which was generated by deleting the document.
>From my understanding this means, if you want to resurrect deleted
documents,
you have to do it before compaction happens.
So, are the following steps the right approach for un-deleting documents? :
1) Don't run compaction
until you un-deleted all the documents you want
2) Re-load a deleted document with a revision ID
previous to the delete to get back the data
and not only the stub of the document
3) Save it back but use the latest revision ID
(the one you got after deleting the document)
On Sun, 03 Jan 2010 12:31:31 +0100, fana <fa...@2flub.org> wrote:
> Hi,
>
> I tried your method and it works.
>
> The problem is, that I can undelete a document
> but the data it carried is gone.
>
> It seems this is normal behavior:
>
> "The doc itself is gone, the deleted stub is still there for
> replication conflict resolution."
>
>
http://mail-archives.apache.org/mod_mbox/couchdb-user/200901.mbox/%3C953A38F3-E1AA-4952-BEBA-B6FCECC69D72@apache.org%3E
>
> So you can't really resurrect a deleted document with its data
> or is there some other way?
>
> On Sun, 27 Dec 2009 09:17:53 -0800, Troy Kruthoff <tk...@gmail.com>
> wrote:
>> I believe the revision does change when you delete the doc, meaning
>> the delete will be replicated to your "master" for which you can
>> monitor changes and un-delete the document, causing it's rev to again
>> be modified and re-replicated to the slaves.
>>
>> Troy