Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 30857 invoked from network); 9 Mar 2010 00:27:15 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Mar 2010 00:27:15 -0000 Received: (qmail 79560 invoked by uid 500); 9 Mar 2010 00:26:50 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 79521 invoked by uid 500); 9 Mar 2010 00:26:50 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 79513 invoked by uid 99); 9 Mar 2010 00:26:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Mar 2010 00:26:50 +0000 X-ASF-Spam-Status: No, hits=3.6 required=10.0 tests=FREEMAIL_FROM,FS_REPLICA,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.218.221 as permitted sender) Received: from [209.85.218.221] (HELO mail-bw0-f221.google.com) (209.85.218.221) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Mar 2010 00:26:42 +0000 Received: by bwz21 with SMTP id 21so1390195bwz.35 for ; Mon, 08 Mar 2010 16:26:22 -0800 (PST) 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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=441GLJqcVQc4mUZ/gOxuO1wRb+F2ZBj+7kGTqVJW7IQ=; b=kPIoqxoJBYdhHV+pgTMjwXANmmsCL/vzUfFtz2Du4/ZzEljRQtujSSYWdRts0/95g3 GEPxWJwrvObjXuE/L8hxhpZQist2SYKlOqmDSoC7Q5o38fUXv6RmJ7lXiYMR9dtX3jec P0hWuUc0eKjkT/hBO8IErt+hjg2/BHWxLYzBc= 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 :cc:content-type:content-transfer-encoding; b=vBxTtcaxlQGOwLFj+S2kMJ+tRNMgDG+1CrCen641IOAbHoRa1gDW6T5iA3dNckFs3S L6uZEQNgVBGltUp6Am9lzKxLYag65eatogQxH2q9zBuBxEz70K3mG9ON1r1R0XE4WbuC o+hM7ditYIBBUfEGmR8yCz4IItvgdZRtdXYO0= MIME-Version: 1.0 Received: by 10.204.29.10 with SMTP id o10mr6191462bkc.82.1268094382137; Mon, 08 Mar 2010 16:26:22 -0800 (PST) In-Reply-To: <4B958BA3.2010304@gmail.com> References: <4B958BA3.2010304@gmail.com> Date: Mon, 8 Mar 2010 16:26:22 -0800 Message-ID: Subject: Re: Preserving seq order through replication From: Randall Leeds To: dev@couchdb.apache.org, mhammond@skippinet.com.au Cc: Dirkjan Ochtman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Mar 8, 2010 at 15:43, Mark Hammond wrote= : > I'm not really up on this in any detail, but isn't there the possibility > that 'y' will have had the same edit performed on 2 different nodes, whil= e > 'x' was only edited on one of them. =C2=A0The change to 'y' will not be > replicated at all between the 2 nodes with identical edits, whereas 'x' w= ill > - meaning 'x' will be seen to arrive later than 'y' on one of the nodes? Totally. Depending on any particular seq order is probably a bad idea. I don't think it's appropriate to assume seq is at all meaningful except for sending back in the ?since parameter to _changes. seq for one server should never be assumed to be meaningful on another.