On Wed, Sep 24, 2008 at 10:46 AM, Jan Lehnardt <[EMAIL PROTECTED]> wrote:
> > Anyway, I had a few questions that I hope I'll be able to get some answers >> for. >> merge conflicts - how does couch db decides on "best" revision? >> > > It arbitrarily choses one revision. The only guarantee that is made is that > for > the same conflict all nodes in a CouchDB cluster choose the same latest > revision to ensure data consistency. > How do you ensure that across a cluster, all nodes will select the same version? Assume that I have the following sequence of events: - create doc A (v1) - update doc A from V1 (v2) - update doc A from v1 (v3) - conflict - update doc A from v1 on separate machine (v?) - conflict How does it get resolved? > to get from the code so far are: >> - How is the data stored? I think that it is a binary tree on disk, but I >> am >> not following how updates to that can be safe to do so with ACID >> guarantees. >> > Two questions that are of particular interest to me, and I haven't been > able > > Writes are serialized. Only one write can happen at a time and it is > completely > flushed and committed to disk (2 x fsync()) before another write comes in. > Writes > are append-only. No data is ever overwritten. This gives us the ACID & MVCC > buzzcronyms :-) > Can you speak more on the actual file format? I don't think that I understand how you can have append only with binary trees.
