From user-return-10228-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Apr 21 09:44:01 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 60639 invoked from network); 21 Apr 2010 09:44:01 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Apr 2010 09:44:01 -0000 Received: (qmail 19719 invoked by uid 500); 21 Apr 2010 09:43:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 19387 invoked by uid 500); 21 Apr 2010 09:43:57 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 19362 invoked by uid 99); 21 Apr 2010 09:43:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Apr 2010 09:43:56 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of matt.goodall@gmail.com designates 74.125.82.180 as permitted sender) Received: from [74.125.82.180] (HELO mail-wy0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Apr 2010 09:43:48 +0000 Received: by wyf22 with SMTP id 22so3854514wyf.11 for ; Wed, 21 Apr 2010 02:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=v5immS9Y4XzrQMM41EDE4iMAmmO146buPD4cqUMNhT4=; b=UmGRzIeyC4erKIflRAEoasgJj1vEX53195ETUJ6FlQrXtJWT54zxat2X/6/FBM98BO ByqQaQ8LPb370JHJm/a4MB4PCkHX7qW/xH8HIV5Ndp6m3xM2O+QHgEhBf6oKM6Tg4+NW DhlgeSFIjTrK3z6m7jf263dDlUOtadzROjU/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=E5kYA0NkkZdbyt8IfAwVU2+glOhQ7M2MGcyR2pTOHRJmpI592G+ejBjthdh/a3E9sX RZ3N9yWosee9ZLPbtMdq2WhtuSlApUN07DgX5Lto6e1ZUiaZxyPxDJvSmnXmajupqx+W 9QhFV5NQpvvT/B4cDn+tx4vtvc1v0guSINcRg= MIME-Version: 1.0 Received: by 10.216.53.132 with HTTP; Wed, 21 Apr 2010 02:43:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Apr 2010 10:43:27 +0100 Received: by 10.216.184.195 with SMTP id s45mr1096459wem.28.1271843007909; Wed, 21 Apr 2010 02:43:27 -0700 (PDT) Message-ID: Subject: Re: can you detect consistency? From: Matt Goodall To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On 21 April 2010 10:11, Rachel Willmer wrote: > Say I have 2 couchdb nodes which replicate bi-directionally. > > Is there a way of detecting that they have reached consistency? > (assuming that changes have stopped being made and that the > replication has done its thing) > > By trial and error, I can see that in a scenario where I have two > nodes which do in fact have the same data (which I've verified by > scripting a doc-by-doc check that their revs are the same, and their > contents are the same); in that scenario, the update_seq is different > on the two nodes. > > So I have 2 questions: > > a) is that expected or a bug? (my guess is that it's expected) I assume you mean the differing seq nums here? Yes, it's expected. The seq num is local to each database. > > b) is there any other way of detecting consistency quickly? As you discovered, once bi-di replication has completed the revs of the replicated docs are the same in both databases. This is by design. In the case of a conflict, CouchDB picks the winning rev in a predictable way to ensure that even conflicts are eventually consistent. I don't know of anything at the database level you can actually check to test for consistency but assuming nothing is writing to either database during replication then knowing that replication is complete should be enough. - Matt