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
