couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: When is _replicate synchronous?
Date Thu, 20 Jun 2013 17:55:09 GMT
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 <rnewson@apache.org> 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 <rnewson@apache.org> 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 <jens@couchbase.com> 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

Mime
View raw message