Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 65904 invoked from network); 29 Mar 2010 01:58:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Mar 2010 01:58:51 -0000 Received: (qmail 88505 invoked by uid 500); 29 Mar 2010 01:58:50 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 88473 invoked by uid 500); 29 Mar 2010 01:58:50 -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 88465 invoked by uid 99); 29 Mar 2010 01:58:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Mar 2010 01:58:50 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wobbet@gmail.com designates 209.85.217.228 as permitted sender) Received: from [209.85.217.228] (HELO mail-gx0-f228.google.com) (209.85.217.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Mar 2010 01:58:43 +0000 Received: by gxk28 with SMTP id 28so1638213gxk.12 for ; Sun, 28 Mar 2010 18:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:content-type; bh=goHR04gkNJ/HMcCl5NDRfFqfyFou8/HWCqO4uE1jvlc=; b=X18ly4/UiL2Dxw8g9ThOysNkC480PfrrLZNfiPZjL4doio2Nov+7Awp5WgL+Jx338H XG9hhxfrOeBp8ZMCrnWKlc2v4/6aAHMZCR+cAOq+LCX6Fi32ybikWW+/PNyCH2v4LcIV rTxIJHBCB+OHmMkdCVcezrXrAf898nucnUR14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=IE8ozPPedm70LNMP/RlwhZGb61GBfVzZQfG16FHmg6RTZE7C7wSoeFCrOoaoxSw6Lf 2LlTRWOpqcRU34t3pVReb5EEyu+6dAQdmXYoT0mvPal2korQSL1zHt97uuDyGKFi5te5 E9KcbCy1GCboWGx49M2klGtwswNkZLAqrRfAg= MIME-Version: 1.0 Received: by 10.100.108.16 with HTTP; Sun, 28 Mar 2010 18:58:22 -0700 (PDT) Reply-To: wobbet@wobbet.com In-Reply-To: <4BAFF265.8070202@gmail.com> References: <4BAFF265.8070202@gmail.com> Date: Sun, 28 Mar 2010 20:58:22 -0500 Received: by 10.101.202.39 with SMTP id e39mr4934996anq.109.1269827902530; Sun, 28 Mar 2010 18:58:22 -0700 (PDT) Message-ID: Subject: Re: Deciding on the structure of documents From: Robert Sanford To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e68d37820f19740482e6d977 --0016e68d37820f19740482e6d977 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 28, 2010 at 7:20 PM, Patrick Barnes wrote: > For the single-document situation: What if multiple people reply to the > same post at the same time? The first comment to reach couchdb would succeed > in updating the document, and the second comment would result in an error, > because the doc revision is now out of date. A single-document situation > would require the application logic to handle a revision error, and maybe > automatically resubmit. This solution does not scale well - the more traffic > and the more comments a site receives, the more likely these revision errors > will occur. > This brings up a question on an app I'm in the process of designing and I'm wondering how it works in a multi-node situation. In my app a document (almost literally a document actually) can have a single caretaker. In some situations the owner can decide they no longer wish to act as caretaker and offer up the document to others. That situation is easy in that the role of caretaker is explicitly transferred. Or, they can simply release "ownership" of the document.In that instance others that are assigned the role of Caretaker in the system can then claim the document on a first-come-first-served basis. In a multi-node system w/ replication what happens if Caretaker D in the Dallas office claims the document and prior to any replication occurring Caretaker P in the Phoenix office also claims the document? How can that sort of situation be handled? In a single-node system it's (not quite) trivial to handle but in a multi-node system w/ a time delay between replications that are not taking business logic into account that is trickier and I don't have my head around it yet. rjsjr --0016e68d37820f19740482e6d977--