couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Do we need 2 entry points for the replication?
Date Thu, 19 Jan 2012 21:56:59 GMT
On Thu, Jan 19, 2012 at 3:52 PM, Robert Newson <rnewson@apache.org> wrote:
> I would prefer to see a single /_replicate entrypoint, with, say,
> "persistent":true to indicate that the replication settings should be
> stored. We would also need an API to list all persistent replication
> tasks and one to delete them. Which would look a lot like the
> _replicator database, though much more controlled (no public passwords
> for those jobs that require auth).
>

+1

> I think it's too late, though. There's work on master to fix the
> issues with _replicator now (and the similar ones in _user). While I
> don't like the approach, it does solve the problem.
>

We can break it eventually and I think we should consider it sooner
rather than later.

> Bottom line: It's my opinion that _replicator (and _user) were wrongly
> exposed as full-blooded databases when all  we needed to use was the
> database format (and carefully curate API endpoints). But, alas, that
> train has sailed.
>

I seem to recall someone else with a similar opinion even when these
things were being designed. ;)

Also, what kind of crazy sailing trains do you brits have over there
and how do I get a ticket to ride on one?

> B.
>
> On 19 January 2012 21:45, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> Think it's time to relaunch this threads following the 2 separate
>> discussions that we had this morning. Actually we have 2 ways to
>> handle the replication:
>>
>> - `_replicate` : which isn't persistent and where you can follow the
>> task in active tasks
>> - `_replicator`: wich is a plain db where any replication task is
>> persistent. In that case even if a replication task is finished, a
>> document stay in the replicator db and you will have to delete it and
>> compact the db from time to time.
>>
>> Both are their use cases, and while i think it's good to keep the
>> different approaches (persisten against fire and forget), I think the
>> API should be more consistent by offering only 1 end point for the
>> replication. We could then having different parameters depending on
>> the replication type we want (persistent or fire and forget). Also
>> both should appear in the active tasks (maybe this point have been
>> solved since).
>>
>> So I  propose to keep only one entry point : _replicate and pass the
>> parameter we want to it. What do you think ?
>>
>> - benoit

Mime
View raw message