Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Sender: J Chris Anderson <jchris@couch.io>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: _replicator DB
From: J Chris Anderson <jchris@apache.org>
In-Reply-To: <AANLkTilMIYptuYaMBkm83GLAg6MgT4_yYThtRUkKbsk8@mail.gmail.com>
Date: Wed, 19 May 2010 14:32:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A76E3FF-5839-4B48-855E-8A35B7E7A0AE@apache.org>
References: <AANLkTikB7mk1x_PuQawDgiQB0tUplXxQD6soVdnUBRDR@mail.gmail.com>
 <8A1BC8DD-9794-4D6C-8441-09ACDEAA5CA6@dionne-associates.com>
 <AANLkTil7H2k6JUoWKSELCO2QfV_Ef1uNNqWfuQyjnmQZ@mail.gmail.com>
 <92361758-9D77-430A-A88E-C1995D75453A@googlemail.com>
 <3F7A5FFF-56D0-411E-B8A9-938D335E719B@googlemail.com>
 <AANLkTindP5wUvUS3rAvs6Skrfa-hzfXcuDYk2lTSXiIm@mail.gmail.com>
 <6878CABA-4EA0-41C6-84EF-0BE494BCFC9F@apache.org>
 <B8203398-B2AD-493D-B503-34F578B36BC8@apache.org>
 <AANLkTingqAvAOkdNIBLSdm8YUQdBgq5Dyw24AbjL7eqk@mail.gmail.com>
 <AANLkTilMIYptuYaMBkm83GLAg6MgT4_yYThtRUkKbsk8@mail.gmail.com>
To: dev@couchdb.apache.org


On May 19, 2010, at 2:17 PM, Randall Leeds wrote:

> On Wed, May 19, 2010 at 13:06, Filipe David Manana =
<fdmanana@gmail.com> wrote:
>> Answers bellow
>>=20
>> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocolosk@apache.org> =
wrote:
>>>>=20
>>>> 3) Is the checkpoint ID generation algorithm backwards-compatible?  =
Or
>>> will users who upgrade restart all replications from scratch?
>>>=20
>>=20
>> Well, the checkpoint IDs will be "_local/" + repDocId. So, they are
>> basically user generated. Checkpoints will still remain in the source =
and
>> target DBs (I don't write them to the _replicator DB).
>=20
> So if I create a _replicator doc with an ID corresponding to an
> old-style replication ID it'll use the same checkpoints?
>=20
> I can't remember, is it possible to change the doc_id with an _update
> handler? I haven't looked at your code yet to see what paths it takes,
> but if it's an erlang handler in the .ini I'm sure we could hack this.
> Basically, I'm thinking to make _replicator a lot like the _replicate
> from an API standpoint. Disable PUT but have POST to _replicator
> create the doc with the rep id as we used to calculate it.
>=20
> In fact, why name it _replicator at all??? We already have a POST to
> _replicate that returns the id. This API looks a lot like the document
> API, we just create a gen_server instead of a document. But if we're
> careful couldn't we transparently turn the _replicate endpoint into
> the _replicator DB under the hood and users don't even have to know
> the difference (unless they need/want to)?
>=20
> -Randall


[retry after a delivery failure from gmail. maybe something is up with =
Apache servers?]

The main goals as I see them are:

1) replications continue even when the server restarts
2) it is easy to write replication manager couchapps

I think having the standard database API for these documents (even if it =
is admin only) will be a good way to allow people to use the existing =
toolkit to query and create replications.

Of course it'd be nice to be backwards compatible with the existing =
replication API.

Chris=