Hi Markus, that's good advice, thanks. And thanks for the plug :)
Cheers Jan -- On 10 Dec 2009, at 14:11, Markus Jelsma wrote: > 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 > > >
