couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: struggling with couchdb in production
Date Tue, 26 May 2009 07:39:47 GMT
On Mon, May 25, 2009 at 12:36:11PM -0700, Chris Anderson wrote:
> > a database in couchdb is the place where work comes together, in our case
> > this is the location where a group of people shares. combining information
> > from different databases will be necessary. and i really have no clue yet
> > how to approach this problem. so anyone?
> The easiest thing is to merge the databases with replication.

In some ways this is the easiest - and in some ways it is the hardest.

It will be easy if your various sources are creating distinct documents. It
will be hard if the various sources are editing the same documents - because
you will start having to deal with replication conflicts.

Whilst CouchDB's model for this is logically self-consistent, I personally
still believe that it's difficult to use for real-world applications. For
example, if you GET a document, you will get one arbitrary version. You will
get no indication that conflicting versions of this document may or may not
exist. If you want to ensure that your user always sees the latest, resolved
version of the document, then you need to explicitly ask for all the
conflicting revisions, and then you need to fetch them individually (AFAICS,
even a regular "bulk fetch" using _all_docs and keys can't do this), and
then merge them in an application-specific way, and then put back the merged
version and delete all the conflicting revs.



View raw message