You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2013/06/20 19:41:19 UTC
When is _replicate synchronous?
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
Re: When is _replicate synchronous?
Posted by Robert Newson <rn...@apache.org>.
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 <rn...@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 <rn...@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 <je...@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
Re: When is _replicate synchronous?
Posted by Robert Newson <rn...@apache.org>.
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 <rn...@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 <je...@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
Re: When is _replicate synchronous?
Posted by Robert Newson <rn...@apache.org>.
_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 <je...@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