On Sep 26, 2012, at 8:34 AM, Frank Wunderlich <[email protected]<mailto:[email protected]>> wrote:
But unfortunately we have got a quite "relational" document model. One logical "asset" consists of several CouchDB documents, referencing each other. The filter functions can only access data, that is part of the document that is passed in as parameter. Because of this limitation, each partial document must contain all the information necessary, to determine whether it shall be replicated or not. Yes. In a document database you generally want documents to be less interdependent than in a relational DB, so adding extra info to the pieces seems appropriate. This leads to redundancy and to potential inconsistencies if a "transaction" fails. Inconsistent asset aggregates might get "partially" transferred to other CouchDB instances. Redundancy is part of the tradeoff in a non-relational DB. The inconsistencies you describe could occur with any kind of replication, even unfiltered, since docs are transferred one-by-one. You can have partial states where an app looks at the database in the middle of a replication, and you can have error states where one or more docs failed to transfer but the replicator hasn’t gotten around to retrying them yet. This is all part of the loss of Consistency (the “C” in the “CAP Theorem”.) You need to design a schema that can handle it. —Jens
