On Fri, Mar 13, 2009 at 11:03:30AM +1030, Antony Blakey wrote: > > On 13/03/2009, at 10:45 AM, Chris Anderson wrote: > >> It seems like most of these problems just go away if you >> put all the data that needs to be edited transactionally into a single >> document. > > There is a tradeoff between document granularity and concurrency.
Indeed, and a subheading under "concurrency" is "ease of conflict resolution". I am tring to get around to writing up the "simple" and oft-quoted example of a replicated set of bookmarks. I don't think it's as simple as is claimed. If you keep all your bookmarks in one document it's easy as pie to program with, until you get a replication conflict, in which case couchdb gives you no help whatsoever. It just tells you that here are two different sets of bookmarks. People expect that a bookmark added on A will also be added on B, and a bookmark deleted on A will also be deleted on B. If you move to one-couchdb-object-per-bookmark then the replication becomes much easier to deal with. But then you have to deal with the relationships between documents - e.g. people expect their bookmarks to be ordered and nestable. Regards, Brian.
