couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <fdman...@gmail.com>
Subject Re: _replicator DB
Date Thu, 20 May 2010 08:47:43 GMT
On Wed, May 19, 2010 at 10:17 PM, Randall Leeds <randall.leeds@gmail.com>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?
>

Yes.


>
> 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.
>

That's a good observation.

I thought about changing the ID of replication docs with an _update handler,
to make sure they would be the same as the current replication IDs (the md5
of a term_to_binary of a term containing the replication properties). Doing
that in a JavaScript _update handler is not possible, because of the
term_to_binary call and the need of an md5 function.

Also, for allowing users and couchapps to manage replications, it's more
"relaxing" to allow them to choose whatever ID they want to identify a
replication -> I think this is a plus.

Yes, a replication document is basically a JSON object that we currently
POST to _replicate. Only with an "_id" field and a "state" field, everything
else is the same.


>
> 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)?
>

Initially I had code that created a replication document in _replicator DB
when POSTing to _replicate. It turned out to add many ugly logic to
couch_rep.
Is that what you had in your mind?


>
> -Randall
>



-- 
Filipe David Manana,
fdmanana@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message