I believe Jim is referring to the replication checkpoint document (which does indeed include 'historical' information). Jim is also correct in that the presence of this document will prevent a full re-replication when the target's validate_doc_update function is altered.
Jim, the replication checkpoint document is named in the way: /dbname/_local/<hash>. You should be able to see this document being written to in the logs and the <hash> portion is also the value you get back when POST'ing to _replicate (and the one shown in _active_tasks). Delete the document in the usual fashion and replication will do over from the start. B. On 24 December 2011 11:56, Dave Cottlehuber <[email protected]> wrote: > On 24 December 2011 02:30, Jim Klo <[email protected]> wrote: >> Trying to test a validate_doc_update function for use in replication. >> >> Is there a way to reset or delete the replication history so I don't have to >> continuously recreate my target db? >> >> Thanks, >> >> - Jim > > Jim, > > There's no such thing as a replication history, only replicated > documents. So you have a few choices; > > Recreate your db if you're starting from scratch this is as simple as > an additional line in your test script, curl -X DELETE $DB ; curl -X > PUT $DB. > > If you're not starting from scratch, then you can simply copy the > fresh db somewhere as a backup, and re-copy it back with, say, rsync, > > You may find it easier to start a js interpreter up and work through > the validation function directly, using the process outlined in > http://wiki.apache.org/couchdb/Troubleshooting#Map.2BAC8-Reduce_debugging > obviously you'll need to get a sample userCtx as well. I would think > you can use the same logging function as the view server "log(stuff);" > to do this. Note this is not for use on production DBs due to heavy > perf impact. > > Pro-tip: don't forget to accept all _deleted docs through your > function to ensure MVCC continues to work as expected. > > A+ > Dave
