Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DHOaF3=cXu7ww4aG2Q8XsSEiPBiKU50rLXWO6Nn9DW-BA@mail.gmail.com>
References: <6114AB2E-A404-4050-B415-DDF5C6F99241@couchbase.com>
	<CABvT1DFHnU0BfeXJKsd+qFNtLGpTaj0yK3=vddWSOXYCY6D=QQ@mail.gmail.com>
	<CABvT1DHOaF3=cXu7ww4aG2Q8XsSEiPBiKU50rLXWO6Nn9DW-BA@mail.gmail.com>
Date: Thu, 20 Jun 2013 18:55:09 +0100
Message-ID: 
 <CABvT1DESCSyUtTk_sQ=Tt=GMLwi2prS9Yw-xffKp9e0j9QU3yQ@mail.gmail.com>
Subject: Re: When is _replicate synchronous?
From: Robert Newson <rnewson@apache.org>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Cc: Filipe Manana <filipe@couchbase.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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=92t say so, but in practice the call a=
ppears to be synchronous unless the =91continuous=92 property is set. That =
is, it doesn=92t return a response until the replication completes, and in =
fact the response JSON includes a bunch of statistics about the replication=
.
>>>
>>> I didn=92t know this when I implemented TouchDB, so I made _replicate a=
lways asynchronous. (It made more sense to me, especially since my client c=
ode 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=92m amending this now for Couchbase Lite, but I=92d like to make sure=
 I know the semantics. Is it true that it=92s always synchronous unless con=
tinuous=3Dtrue, and then it=92s asynchronous?
>>>
>>> Also, is there any description somewhere of what the properties in the =
synchronous response mean? Some are obvious, some less so. Here=92s an exam=
ple 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=92m particularly curious (a) why =93history=94 is an array, and (b) w=
hat =93replication_id_version=94 means.
>>>
>>> =97Jens