incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@couchbase.com>
Subject Any way to explicitly skip design docs in replication?
Date Tue, 29 Nov 2011 20:49:14 GMT
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.

* We’ve also run into issues where two independently developed native apps that operate
on the same data set each create a design doc for their views … and unintentionally give
those design docs the same name. This then results in a conflict whenever these apps both
try to replicate with the same database. (This is happening with our iOS and Android ‘Grocery
Sync’ apps.) In this case it’s obvious that the design docs are purely part of the app
implementation, not part of the data set, and should never be replicated.

* A similar thing happens if two versions of a native app sync to the same database, and in
version 2 the design document was changed in a way that’s incompatible with version 1. After
bidirectional syncing, one of the apps is likely to be broken since the ‘winning’ version
of the design doc will be the one that it’s not compatible with.

SUGGESTION:
Due to this, I would like replication of design docs to be optional. I suggest adding something
like a “designdocs”:false property in the replication’s JSON configuration.

Yes, it is possible to write your own filter function that skips design docs. But this then
has to be implemented in every app; I don’t think there’s a way to factor this out so
it can be handled by a framework (like my CouchCocoa) without the app developer having to
do the work.

Comments? Has this been brought up before? Is there a ticket for it or should I file one?

—Jens


Mime
View raw message