couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: The replicator needs a superuser mode
Date Wed, 17 Aug 2011 10:06:20 GMT
On Wed, Aug 17, 2011 at 5:37 AM, Jason Smith <> wrote:
> tl;dr response here, philosophical musings below.
> 1. The requirements are real, it's reasonable to want to copy from A to B
> 2. Replication is a whole worldview, adding ?force=true breaks that worldview
> 3. Dump and restore sounds more appropriate
> On Wed, Aug 17, 2011 at 9:34 AM, Adam Kocoloski <> wrote:
>>> But to "guarantee all my documents are stored in this other database"
>>> is actually incoherent. It is IMHO anti-CouchDB.
>> Hi Jason, we're going to have to disagree on this one.  Replication is really flexible
and can do lots of things that database replication has not historically been able to do,
but I think it's a sad state of affairs that it's not possible to use replication to create
a replica of an arbitrary database.
> True. I agree with the requirements, but the solution raises a red flag.
> My understanding of couch:
> There is no such thing as a database (or data set) clone. There is no
> such thing as a database copy. There is no such thing as two databases
> with the same document.

At some time there can be clone or frozen dbs. So sure it can exists.
There are some use cases for that.

 It's like Pauli's exclusion principle. Sure,
> maybe the doc and rev history are the same, but the _security object,
> the authentication environment, and the URI are different. That
> (generally) affects how applications and validation works.

But that can happen differently.

> Put another way, this idea is a leaky abstraction. I much prefer Jan's
> _dump and _restore idea. It has some difficulties, but it is *not*
> replication. It's something totally different. In the universe of a
> database, replication always follows the rules. In the universe of a
> Couch, sure, sometimes you need to clone data around. There's an
> appropriate action for each abstraction layer.
> The nice thing about _dump and _restore, and also rsync, is that you
> make full, opaque clones (not replicas!). You can't merge or splice
> data sets. Once you are talking about merging data, or pulling out a
> subset, now you are in database land, not couch land, and you have to
> follow the rules of replication.

Philosophy apart, dump and restore could be indeed useful to bootstrap
db, make plain backup/restore strategies, exchange dbs over a disk/mem
card without any couch installed etc.

I was playing with this idea last day since it will be useful in
refuge project (for other purpose than backup).

Features I drafted:
- ability to have a compacted dump
- dump can be done from a sequence and restored from
- dump can be merged in another db

Questions I still had to solve:
- What do we do with design document and especially validation
functions? Do we bypass them during the restore?
- What about security object? In some usecases it may be interrested
to lock the database to same kind of readers & .
- Would it be useful to crypt he dump from couch ? Or let this one to
an external program ?


View raw message