couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Petersen <christopher.peter...@gmail.com>
Subject Re: design document replication
Date Fri, 29 Jan 2010 19:05:01 GMT
Thank you all for your help. Configuring an admin account and having the
replication run as a regular user worked perfectly.

Thanks!
Chris

On Thu, Jan 28, 2010 at 9:39 PM, Chris Anderson <jchris@apache.org> wrote:

> On Thu, Jan 28, 2010 at 7:31 PM, Paul Joseph Davis
> <paul.joseph.davis@gmail.com> wrote:
> >
> >
> >
> >
> > On Jan 28, 2010, at 10:23 PM, Chris Anderson <jchris@apache.org> wrote:
> >
> >> On Thu, Jan 28, 2010 at 6:11 PM, Paul Davis <
> paul.joseph.davis@gmail.com>
> >> wrote:
> >>>
> >>> On Thu, Jan 28, 2010 at 9:00 PM, Jan Lehnardt <jan@apache.org> wrote:
> >>>>
> >>>> On 28 Jan 2010, at 16:13, Chris Petersen wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I'm currently replicating 3 databases between 4 different CouchDB
> >>>>> servers.
> >>>>> Replication works great, however each server is performing a slightly
> >>>>> different task and has slightly different views and specifically
> >>>>> different
> >>>>> validation_rules. Currently  the replication is overwriting all
the
> >>>>> design
> >>>>> docs, thus replacing my customized views and rules. How can I keep
> the
> >>>>> design docs from replicating? Is there a test I can put in the
> >>>>> validation_rules?
> >>>>
> >>>> var design = "_design";
> >>>> if(doc._id.substr(0, design.length) == design) {
> >>>>  throw({forbidden:"no_ddocs"});
> >>>> }
> >>
> >> This actually won't work as described as validation funs are not run
> >> against design doc updates. see couch_db.erl's validate_doc_update().
> >> I think the code is right not to work this way.
> >
> > Hah! And if that function did work it would prevent any update to any
> design
> > doc. You couldn't even delete the design doc preventing the updates. Well
> > maybe with a purge, are those validaed?  Either way, not the answer.
> >
> > Though I'm not certain about the replicate as not admin solution. It'd
> work
> > but seems less than optimal.
> >
>
> This is the common case. It's only on Admin Party couches that normal
> users would ever replicate design docs.
>
> I'd like a facility for admins to act without admin powers normally,
> and then invoke some commands as admin. Think sudo, but for couchttp
>
> >
> >> Instead, design doc updates can only be made by db-admins, so if you
> >> make sure the user that is doing the replication isn't a db-admin,
> >> then the design docs will be skipped.
> >>
> >> The upcoming 0.11 release will make it a lot easier to manage db-admins.
> >>
> >> Chris
> >>
> >>>>
> >>>> Cheers
> >>>> Jan
> >>>> --
> >>>>
> >>>>
> >>>
> >>> And that should be place in each database as an update validation
> >>> function. Probably easiest to put it in a design doc and then special
> >>> case it and it'll just spread through the cluster.
> >>>
> >>
> >>
> >>
> >> --
> >> Chris Anderson
> >> http://jchrisa.net
> >> http://couch.io
> >
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message