On Sun, Jan 3, 2010 at 7:16 AM, fana <[email protected]> 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 <[email protected]> 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/%[email protected]%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 <[email protected]> >> 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
