Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3F6307EBC for ; Wed, 17 Aug 2011 10:07:06 +0000 (UTC) Received: (qmail 13296 invoked by uid 500); 17 Aug 2011 10:07:04 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 12983 invoked by uid 500); 17 Aug 2011 10:06:52 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 12956 invoked by uid 99); 17 Aug 2011 10:06:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Aug 2011 10:06:47 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.215.172 as permitted sender) Received: from [209.85.215.172] (HELO mail-ey0-f172.google.com) (209.85.215.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Aug 2011 10:06:40 +0000 Received: by eye4 with SMTP id 4so669359eye.17 for ; Wed, 17 Aug 2011 03:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+OUy6+nlRHS5cXKNw2vHcNQLvZrG6+3GNDaqMbbADs0=; b=m2W/MwfSxOMB04PqWBqv1wxzVrtMVZ40wJBguGxLcfqlhXfYQFcWvwD/qMfGjcu6pc OClEDUveFYnXQ4ztGdQRHazhoQwop8a4Ka6yo+/GScFFWm7tY5I/PeH28DLlDe7rxqfz NEWyg+c79GdlCuptQgfMAdv97YM6TQqbWWarA= MIME-Version: 1.0 Received: by 10.213.4.10 with SMTP id 10mr689049ebp.43.1313575580695; Wed, 17 Aug 2011 03:06:20 -0700 (PDT) Received: by 10.213.14.196 with HTTP; Wed, 17 Aug 2011 03:06:20 -0700 (PDT) In-Reply-To: References: <4E4AB70F.5040302@fiset.ca> <92F4FAA3-8193-470A-B339-67DA369071B8@apache.org> <9B06CCD6-466C-4548-B646-293B331557FA@apache.org> Date: Wed, 17 Aug 2011 12:06:20 +0200 Message-ID: Subject: Re: The replicator needs a superuser mode From: Benoit Chesneau To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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=3Dtrue breaks that wor= ldview > 3. Dump and restore sounds more appropriate > > On Wed, Aug 17, 2011 at 9:34 AM, Adam Kocoloski wro= te: >>> 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. =A0Replication is= really flexible and can do lots of things that database replication has no= t historically been able to do, but I think it's a sad state of affairs tha= t 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 ? -beno=EEt