You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Chris Anderson <jc...@apache.org> on 2010/01/03 17:23:33 UTC

Re: Questions on replication (how to prevent DELETEs and resync deleted documents)

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