On Wed, May 19, 2010 at 10:17 PM, Randall Leeds <randall.le...@gmail.com>wrote:
> On Wed, May 19, 2010 at 13:06, Filipe David Manana <fdman...@gmail.com> > wrote: > > Answers bellow > > > > On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocol...@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, fdman...@gmail.com
