From user-return-7980-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Dec 10 22:12:16 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 27003 invoked from network); 10 Dec 2009 22:12:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Dec 2009 22:12:16 -0000 Received: (qmail 71754 invoked by uid 500); 10 Dec 2009 22:12:15 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 71663 invoked by uid 500); 10 Dec 2009 22:12:15 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 71653 invoked by uid 99); 10 Dec 2009 22:12:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 22:12:15 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [212.61.9.20] (HELO mail1.nl.clara.net) (212.61.9.20) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 22:12:05 +0000 Received: from claranet.nl (bifur.vianetworks.nl [212.61.15.16]) by mail1.nl.clara.net (Postfix) with SMTP id 05F2C359054; Thu, 10 Dec 2009 23:11:44 +0100 (CET) Received: from 82.73.244.17 (SquirrelMail authenticated user buyway58) by webmail.claranet.nl with HTTP; Thu, 10 Dec 2009 23:11:45 +0100 (CET) Message-ID: <57682.82.73.244.17.1260483105.squirrel@webmail.claranet.nl> Date: Thu, 10 Dec 2009 23:11:45 +0100 (CET) Subject: Re: Should I use CouchDb? From: "Markus Jelsma" To: In-Reply-To: <1260466775.3169.24.camel@leonardo-laptop> References: <1260460317.3169.18.camel@leonardo-laptop> <1260466775.3169.24.camel@leonardo-laptop> X-Priority: 3 Importance: Normal Cc: Reply-To: markus@buyways.nl X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org You should read throug the entire book but your questions are mostly answered in these chapters: - http://books.couchdb.org/relax/intro/eventual-consistency - http://books.couchdb.org/relax/reference/replication - http://books.couchdb.org/relax/reference/conflict-management To summarize; CouchDB utilizes a non-locking multi version concurrency controler (MVCC) to allow for disconnected instances to CRUD the documents, which results in eventual consistency. There exists no concept of locking but CouchDB's versioning system allows for handing document conflicts. These conflicts can and will rise in single but also multiple disconnected instances. In single instances the developer must provide the end-user with a mechanism to handle document conflicts or automate the process. During replication, CouchDB uses an arbitrary algorithm which choses a winner for conflicts. CouchDB's conflict handling and versioning may be explained as somewhat similar to subversion and friends. Although you may be very enthusiastic, you must read the book and forge some experiments for your use-case before actually going for it. There may be pitfalls. In any case, the wiki's and this list will be helpful during your development. Leonardo M. Ramé wrote: > > Knowing this, I seems that CouchDb is the way to go. In my model, each > health organization have a database server that must replicate its data > in planned intervals, twice a day for example. > > This raises a question. Does the Replicator sends the whole database > from one server to another then do a diff between them?, or it has a > more lightweight approach?. > > -- > Leonardo M. Ramé > http://leonardorame.blogspot.com