couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: Selective Replication
Date Wed, 26 Sep 2012 17:48:48 GMT

On Sep 26, 2012, at 8:34 AM, Frank Wunderlich <<>>

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message