incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Any way to explicitly skip design docs in replication?
Date Wed, 30 Nov 2011 14:18:26 GMT
We could add another built-in filter to complement _design (which only
includes design docs), _not_design (or something less silly than that
even). Would be trivial and would avoid this class of problems.

As for treating a validate_doc_update in an unsupported language as if
it's not there, I'm hugely -1 on that, what a giant hole in our
security model. a 400 Bad Request response for invalid ddocs is a
great idea. Adam independently suggested the same for map/reduce/etc
functions that don't *compile*, and this adds even more value to that


On 30 November 2011 00:08, Jason Smith <> wrote:
> Hi, Jens. You raise thought-provoking questions, as usual! IMHO,
> extending the "standard library" of prefab filter functions sounds
> nice.
> Also, Adam proposed a similar feature to ignore validation functions
> on the target couch. You may want to reread it and get some ideas.
> Submitted without commentary: you can find the thread by adding
> "worldview" to your search. :)
> On Wed, Nov 30, 2011 at 3:49 AM, Jens Alfke <> wrote:
>> Replicating design docs seems to be problematic for native apps (or just non-CouchApps).
We’ve run into several issues caused by it, in Couchbase Mobile:
>> * If you don’t have admin privileges to a remote DB you’re pushing to, you’ll
get an error message spammed to the log for every design doc in the local database, which
makes it look like the replication is failing. There have already been several posts to the
mobile-couchbase mailing list by worried developers noticing this message in their console
output and wondering what’s wrong.
>> * If you do have admin privileges, a design doc pushed to a different server may
not work there due to varying language support. For example, I can write functions in Erlang
in my local server, but they won’t be allowed to run on IrisCouch [I think]. Similarly,
Couchbase Mobile for iOS now supports functions that call into native code, but the “objc”
language ID isn’t recognized by any other server. This makes the resulting functions not
>> * An especially bad corollary of the above is that if you replicate a design document
containing a _validation_ function in a language that’s unsupported at the destination,
the destination database will now *refuse to update any documents*. This makes the rest of
the replication fail, and generally breaks the database completely until someone uses Futon
or curl to delete or edit the offending design doc.
> This one strikes me as a CouchDB bug independent of the other
> problems. CouchDB knows the languages it supports. When Couch receives
> a design document with an unsupported language, it seems like it
> should do one of two things:
> a) Reject the document as invalid (similar to how it would reject
> invalid JSON syntax)
> b) Accept the document and no-op the validations. (Seems more sensible)
> --
> Iris Couch

View raw message