couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: _replicator DB
Date Wed, 19 May 2010 21:17:08 GMT
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

Mime
View raw message