The history array is used so that the replicator can find a common replication record so we don't have to start from 0.
On 20 June 2013 18:53, Robert Newson <[email protected]> wrote: > the id version reflects an internal detail. The scheme for deriving > replication ids changes over time but to prevent redo-from-start, > we'll look for values generated with older versions of the scheme in > the event of a miss (a missing _local checkpoint doc). > > Is it necessary to CC Filipe's work email address? His apache.org > address should receive this. > > B. > > > On 20 June 2013 18:51, Robert Newson <[email protected]> wrote: >> _replicate was always a blocking call, and then we added continuous >> replication. Obviously it then makes no sense to wait for "the end". >> >> B. >> >> >> On 20 June 2013 18:41, Jens Alfke <[email protected]> wrote: >>> The wiki docs for _replicate don’t say so, but in practice the call appears >>> to be synchronous unless the ‘continuous’ property is set. That is, it >>> doesn’t return a response until the replication completes, and in fact the >>> response JSON includes a bunch of statistics about the replication. >>> >>> I didn’t know this when I implemented TouchDB, so I made _replicate always >>> asynchronous. (It made more sense to me, especially since my client code >>> needed to be able to track the progress of a replication using >>> _active_tasks, which meant it needed a response ASAP so it could get the >>> task ID.) >>> >>> I’m amending this now for Couchbase Lite, but I’d like to make sure I know >>> the semantics. Is it true that it’s always synchronous unless >>> continuous=true, and then it’s asynchronous? >>> >>> Also, is there any description somewhere of what the properties in the >>> synchronous response mean? Some are obvious, some less so. Here’s an >>> example from 1.2: >>> >>> { >>> "history": [ >>> { >>> "doc_write_failures": 0, >>> "docs_read": 18, >>> "docs_written": 18, >>> "end_last_seq": 19, >>> "end_time": "Thu, 20 Jun 2013 16:58:13 GMT", >>> "missing_checked": 18, >>> "missing_found": 18, >>> "recorded_seq": 19, >>> "session_id": "1cef7405d0e61fb0decc89323669a012", >>> "start_last_seq": 0, >>> "start_time": "Thu, 20 Jun 2013 16:58:13 GMT" >>> } >>> ], >>> "ok": true, >>> "replication_id_version": 2, >>> "session_id": "1cef7405d0e61fb0decc89323669a012", >>> "source_last_seq": 19 >>> } >>> >>> I’m particularly curious (a) why “history” is an array, and (b) what >>> “replication_id_version” means. >>> >>> —Jens
