Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 30598 invoked from network); 25 May 2009 18:03:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 May 2009 18:03:48 -0000 Received: (qmail 1834 invoked by uid 500); 25 May 2009 18:04:00 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 1754 invoked by uid 500); 25 May 2009 18:04:00 -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 1744 invoked by uid 99); 25 May 2009 18:04:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 May 2009 18:04:00 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FS_REPLICA,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.219.168 as permitted sender) Received: from [209.85.219.168] (HELO mail-ew0-f168.google.com) (209.85.219.168) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 May 2009 18:03:50 +0000 Received: by ewy12 with SMTP id 12so3767109ewy.11 for ; Mon, 25 May 2009 11:03:30 -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:message-id:subject:from:to:content-type; bh=6wS6pcL+YA8YeEbGakHihtvvVIRWKrgBT6wgLCWDdGE=; b=Htukz0zvCsF3ziCYzbE0wBR54J5ED7dL8LPMpdzUvJpu1emyFa+Iy1q/KIRgEb/yh3 /8Aq4TKwkcCokVEGVGarVTTiJdilA03vyDxNn1u8ChNxvK2vvpvZYqOjFFldixnOWZzS OKIBJvLlq8C1H3Q6xoVj4OlG26YotrzGUbtus= 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=fadhczCqhkfALJghGban/QrspUi81PXn2PuPbpjtBqMe6aYDkmQkC93RciaRPXoX5W 6CxEfRLY/Fts/YvhFWPwXwel6na7e91GuhShaHg4lG0Rvy8hRSlzh8wgtHvyTptFR9M5 De2CYIJGhGEoZhuyHm9hFk7jjfM5sgUvqaCVM= MIME-Version: 1.0 Received: by 10.216.1.69 with SMTP id 47mr2059862wec.224.1243274610353; Mon, 25 May 2009 11:03:30 -0700 (PDT) In-Reply-To: <261cf6280905242244l180a942fwf316d45eaa8c3376@mail.gmail.com> References: <067AA5E4-0E5F-46C7-85EE-FC9CBCF99490@apache.org> <261cf6280905242231x2b0e9f67taf37edd015232eb3@mail.gmail.com> <261cf6280905242244l180a942fwf316d45eaa8c3376@mail.gmail.com> Date: Mon, 25 May 2009 14:03:30 -0400 Message-ID: Subject: Re: reiterating transactions vs. replication From: Randall Leeds To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016364d2933822897046ac06da9 X-Virus-Checked: Checked by ClamAV on apache.org --0016364d2933822897046ac06da9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Mon, May 25, 2009 at 01:44, Scott Shumaker wrote: > If that's the case, it does explain why there are some decisions in > CouchDB I find strange, like the fact that authentication runs during > replication. You're using replication for a completely different > purpose than I need it for - I need it for redundancy and read > scaling, you're using it to synchronize disparate data sources. Very > different problems that call for very different solutions. I called out this distinction between usages in my message above. If the replication functionality were "directed" or overseen by the sharding/partitioning code in the data center deployment, I think we can totally prevent replication conflicts *caused by* the partitioning code. However, replicating to/from the data center could still create conflicts in the normal way. --0016364d2933822897046ac06da9--