On Sun, Mar 15, 2009 at 4:55 PM, Brian Candler <b.cand...@pobox.com> wrote:
> 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. I don't think Chris was suggesting you put *all *bookmarks in a single document, just that the transactions themselves can be documents -- think ledger entry in double-entry accounting. In some circumstances you can use a reduce to roll these up into a useful view of your system state. The bookmarks case you mention is interesting -- and definitely common. The ordered list model is tough to accommodate, but you could always keep a doc that maintains this order state. Ordering operations should always occur distinctly from document change operations, so local consistency shouldn't be a problem. But I concede that this'll be damn tough to replicate. Another model -- the one I think Chris was hinting at -- would be to store the relevant properties of every rearrangement operation individually, and use a reduce (admittedly a very complex one) to get at the current ordering. I'm sure that given enough swings at implementation, certain patterns will emerge to make this kind of stuff a lot easier.
