couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@apache.org>
Subject Re: _replicator DB
Date Wed, 19 May 2010 21:32:01 GMT

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
>> 
>> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
>>>> 
>>>> 3) Is the checkpoint ID generation algorithm backwards-compatible?  Or
>>> will users who upgrade restart all replications from scratch?
>>> 
>> 
>> 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).
> 
> So if I create a _replicator doc with an ID corresponding to an
> old-style replication ID it'll use the same checkpoints?
> 
> 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.
> 
> 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)?
> 
> -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
Mime
View raw message