From couchdb-user-return-1348-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Wed Sep 24 07:54:03 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 99571 invoked from network); 24 Sep 2008 07:54:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Sep 2008 07:54:03 -0000 Received: (qmail 84128 invoked by uid 500); 24 Sep 2008 07:53:59 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 84109 invoked by uid 500); 24 Sep 2008 07:53:59 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 84098 invoked by uid 99); 24 Sep 2008 07:53:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Sep 2008 00:53:59 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 209.85.200.173 is neither permitted nor denied by domain of ayende@ayende.com) Received: from [209.85.200.173] (HELO wf-out-1314.google.com) (209.85.200.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Sep 2008 07:52:59 +0000 Received: by wf-out-1314.google.com with SMTP id 27so3156561wfd.21 for ; Wed, 24 Sep 2008 00:53:23 -0700 (PDT) Received: by 10.143.36.15 with SMTP id o15mr2411614wfj.36.1222242803215; Wed, 24 Sep 2008 00:53:23 -0700 (PDT) Received: by 10.142.140.6 with HTTP; Wed, 24 Sep 2008 00:53:23 -0700 (PDT) Message-ID: <27d8d0930809240053y51780222s4c21f23894d455a1@mail.gmail.com> Date: Wed, 24 Sep 2008 10:53:23 +0300 From: "Ayende Rahien" To: couchdb-user@incubator.apache.org Subject: Re: Newbie questions In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_72921_13413622.1222242803212" References: <27d8d0930809231715v379b8d27jd830af5c33ecda8f@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_72921_13413622.1222242803212 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Sep 24, 2008 at 10:46 AM, Jan Lehnardt 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. ------=_Part_72921_13413622.1222242803212--