couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: Delete replication history
Date Tue, 03 Jan 2012 22:33:31 GMT

Say I don't know that <hash> and it isn't in my log; it looks like it's pretty consistent
- what's that a hash of?  can I recompute it programmatically, since there's not exactly a
way to list _local docs?

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International

On Dec 24, 2011, at 4:46 AM, Robert Newson wrote:

> 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 <> wrote:
>> On 24 December 2011 02:30, Jim Klo <> 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
>> 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

View raw message