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 notion. B. On 30 November 2011 00:08, Jason Smith <[email protected]> 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 <[email protected]> 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: >> >> PROBLEMS: >> * 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 work. >> >> * 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 >
