couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: create_target isn't working with the _replicator db
Date Sat, 23 Jul 2011 14:57:53 GMT
Hi Randall,

here's how I see this whole thing:

I think the replicator db API is superior to "old" API.

I think it is perfectly acceptable to have two APIs for the same thing in a transitional period.

I think we should eventually remove all specific code that handles _replicate and have the
_replicator code implement _replicate (In fact that is what Benoit proposed initially and
if I remember correctly, we all thought is was a good idea).

I think when we can (2.0 e.g.) we should deprecate the use of _replicate in favour of _replication
and in a second step remove even the code that we wrote for the previous point.

Right now we are in a transitional period, and yes, that has disadvantages, but I don't see
any immediate way out other than what we have planned or how we should have approached this
differently. I believe everybody (certainly I am) is happy to discuss alternatives.


On 22 Jul 2011, at 20:31, Randall Leeds wrote:

> On Fri, Jul 22, 2011 at 11:26, Randall Leeds <> wrote:
>> On Fri, Jul 22, 2011 at 09:40, Benoit Chesneau <> wrote:
>>> On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana
>>> <> wrote:
>>>> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <>
>>>>> Yup, but I think that's a bug then. I shouldn't have to set any
>>>>> userctx imo. If no admin has been set, every user is an admin except
>>>>> if we change the default behavior and then it's not consistent.
>>>> This was discussed sometime before the 1.1.0 release in the security list.
>>>> And it's a principle of the least privileges by default (roles is an
>>>> empty list).
>>> I've no problem with that, it's even good. But other part of the API
>>> aren't consistent then. While _replicator is ok, I can still do this
>>> operation on _replicate. I propose to port the same behavior
>>> _replicate.OK for that?
>> I'd definitely prefer they be consistent.
>> In fact, I've been arguing quietly for POST to _replicator to be
>> exactly the _replicate API and to deprecate the latter.
>> Isn't this possible?
> What I mean to say is that I think it's absolute craziness to have two
> replication APIs.
> {persist: true} or something would have made more sense to me.
> ?block=true perhaps if we want the old one-shot, blocking. Persist on
> PUT or with {id: <replication_name>}, otherwise make it one-shot.
> I hate to be complaining like this after we've already released it
> with a different API, but I raised this a few times before 1.1 went
> out. I think two APIs for replication is ugly and confusing. A new
> CouchDB user has enough to digest without having to remember that
> _replicate is different from _replicator. I would have preferred we
> papered over the differences as described above and made _replicate
> use a database, rather than create a brand new path.
> </rant>

View raw message