couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fana <>
Subject Re: Questions on replication (how to prevent DELETEs and resync deleted documents)
Date Sun, 03 Jan 2010 15:16:00 GMT

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
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 <> 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."
> 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 <>
> 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

View raw message