Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.218.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YB7_piPuk1PEOOFFf55FP6am1tdODXyFg=xKGdv=2fSSg@mail.gmail.com>
References: <EBDEACDE-17FD-4DD5-8E67-D5A13D69F88E@apache.org>
	<4E4AB70F.5040302@fiset.ca>
	<C3921F01-7545-4B5C-974D-B6BF3E7517EE@apache.org>
	<CAAL6JQifLeSUjBDD9SpVs2Mudg0tBajp63u1_=0MhD=4wjQkzA@mail.gmail.com>
	<CAJ_m3YB7_piPuk1PEOOFFf55FP6am1tdODXyFg=xKGdv=2fSSg@mail.gmail.com>
Date: Tue, 16 Aug 2011 16:49:44 -0700
Message-ID: 
 <CAAL6JQhEJkk6QZHcZNwJnpwo8BsXkYKYsdjF6qLYi-LMtWq6CQ@mail.gmail.com>
Subject: Re: The replicator needs a superuser mode
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=bcaec5299a49bb335604aaa808ca

--bcaec5299a49bb335604aaa808ca
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 16, 2011 at 16:23, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Tue, Aug 16, 2011 at 4:46 PM, Randall Leeds <randall.leeds@gmail.com>
> wrote:
> > -1 on _skip_validation and new role
> >
> > One can always write a validation document that considers the role, no?
> Why
> > can't users who need this functionality craft a validation function for
> this
> > purpose? This sounds like a blog post and not a database feature.
> >
> > +0 on _dump/_load
> >
> > If it ships raw .couch files I'm totally against it because I think the
> HTTP
> > API should remain as independent of implementation details as possible.
> If
> > it is non-incremental I don't see significant benefit, unless it's just
> to
> > traverse the document index and ignore the sequence index as a way to
> skip
> > reads, but this seems like a weak argument. If it's incremental, well,
> then,
> > that's replication, and we already have that.
> >
>
> Think of plain text backups and last resort upgrade paths. Also, it
> wouldn't have validation docs run on it  or anything of that nature.
> I'm thinking basically of having a multipart/mime stream
> representation of the database that follows the update sequence. And
> the _dump would allow for a ?since= parameter that would make it
> incremental. This would even give people the ability to do daily logs
> and so on.
>

Right-o. I don't feel strongly about it, like I said, and think it could be
easily crafted as a plugin if we get *that* situation sorted out.
How's my assessment of the need for a special role or validation skipping,
though? Am I right that one could just create a smart validation function?


>
> > -Randall
> >
> >
> > On Tue, Aug 16, 2011 at 11:40, Adam Kocoloski <kocolosk@apache.org>
> wrote:
> >
> >> Hi Jean-Pierre, I'm not quite sure I follow that line of reasoning.  A
> user
> >> with _admin privileges on the database can easily remove any validation
> >> functions prior to writing today.  In my proposal skipping validation
> would
> >> require _admin rights and an explicit opt-in on a per-request basis.
>  What
> >> are you trying to guard against with those validation functions?  Best,
> >>
> >> Adam
> >>
> >> On Aug 16, 2011, at 2:29 PM, Jean-Pierre Fiset wrote:
> >>
> >> > I understand the issue brought by Adam since in our CouchDb
> application,
> >> there is a need to have a replicator role and the validation functions
> skip
> >> most of the tests if the role is set for the current user.
> >> >
> >> > On the other hand, at the current time, I am not in favour of making
> >> super users for the sake of replication. Although it might solve the
> >> particular problem stated, it removes the ability for a design document
> to
> >> enforce some "invariant" properties of a database.
> >> >
> >> > Since there is already a way to allow a "replicator" to perform any
> >> changes (role + proper validation function), I do not see the need for
> this
> >> change. Since the super replicator user removes the ability that a
> database
> >> has to protect the consistency of its data, and that there does not seem
> to
> >> be a work-around, I would rather not see this change pushed to CouchDb.
> >> >
> >> > JP
> >> >
> >> > On 11-08-16 10:26 AM, Adam Kocoloski wrote:
> >> >> One of the principal uses of the replicator is to "make this database
> >> look like that one".  We're unable to do that in the general case today
> >> because of the combination of validation functions and out-of-order
> document
> >> transfers.  It's entirely possible for a document to be saved in the
> source
> >> DB prior to the installation of a ddoc containing a validation function
> that
> >> would have rejected the document, for the replicator to install the ddoc
> in
> >> the target DB before replicating the other document, and for the other
> >> document to then be rejected by the target DB.
> >> >>
> >> >> I propose we add a role which allows a user to bypass validation, or
> >> else extend that privilege to the _admin role.  We should still validate
> >> updates by default and add a way (a new qs param, for instance) to
> indicate
> >> that validation should be skipped for a particular update.  Thoughts?
> >> >>
> >> >> Adam
> >> >
> >>
> >>
> >
>

--bcaec5299a49bb335604aaa808ca--