couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Joseph Davis <paul.joseph.da...@gmail.com>
Subject Re: design document replication
Date Fri, 29 Jan 2010 03:31:07 GMT




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.


> 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

Mime
View raw message