Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E787C10563 for ; Wed, 20 Nov 2013 22:46:33 +0000 (UTC) Received: (qmail 93022 invoked by uid 500); 20 Nov 2013 22:46:32 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 92968 invoked by uid 500); 20 Nov 2013 22:46:32 -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 92960 invoked by uid 99); 20 Nov 2013 22:46:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Nov 2013 22:46:32 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of simon@cloudant.com designates 74.125.82.47 as permitted sender) Received: from [74.125.82.47] (HELO mail-wg0-f47.google.com) (74.125.82.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Nov 2013 22:46:27 +0000 Received: by mail-wg0-f47.google.com with SMTP id y10so9617591wgg.26 for ; Wed, 20 Nov 2013 14:46:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type; bh=/fL75al5lEldWzr8T2aTKPWYBWj+8lvurCYzzhTEsws=; b=cIhBBObb5bnRMdxGVweXyJnkP3jyMnEyWgMRNtLzXWoH7ITTRMR4lGMkqIDP8GCKsp ttB9/1ypG5WTFwmTirNeMKD4Qf6OsCa+dlE8pi0ksRSROkoBqW+YbGDDIyNyfh95SIsy 5x/M4W/I+bh7vOS2Soje4WFSb4SaLijaCt47QRQzh10CCcNZdB66lhARN3OSz91utMdP M8Hum/I9f9SKOyqXzhP4zfJARIHxkZbcMDhtLP0VFiMqC3Wta2Dk5A7IHpp6lEeKqLlV 14OH/dTnqVeKG2wbGPMnpgLJk3/Y6K4DuhiVI+KsCJJPR+7CHAu+mtjOmDTaCSJZp/HG QvuQ== X-Gm-Message-State: ALoCoQlhNG+VionhhEgub2nI/+gEt8v0YoXzeosjcIWpySNU3JE5rSX6mm63y2z+HWokdkiKG9rl X-Received: by 10.180.183.11 with SMTP id ei11mr3311602wic.10.1384987566250; Wed, 20 Nov 2013 14:46:06 -0800 (PST) Received: from [192.168.1.72] (host-78-146-121-45.as13285.net. [78.146.121.45]) by mx.google.com with ESMTPSA id hv5sm24012wib.2.2013.11.20.14.46.04 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 14:46:05 -0800 (PST) Date: Wed, 20 Nov 2013 22:46:05 +0000 From: Simon Metson To: user@couchdb.apache.org Message-ID: <9549800963374B608978158DC4094778@cloudant.com> In-Reply-To: References: <02EF75D6-C932-4B45-81B4-A8B13D779CD7@couchbase.com> <855F0438-E7A8-43FA-BCD9-91377B4809D2@gmail.com> <25BBCCF8CDC844A5840ED27C1E48F438@cloudant.com> Subject: Re: Considering CouchDB X-Mailer: sparrow 1.3.5 (build 507.62) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="528d3bad_41a7c4c9_1cb" X-Virus-Checked: Checked by ClamAV on apache.org --528d3bad_41a7c4c9_1cb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Nope, views are updated on read, hence the "blocking" behaviour you describe. You can query with update_after, which returns the stale index then triggers the update. On Wednesday, 20 November 2013 at 22:43, Mark Hahn wrote: > I thought that every write triggered a view rebuild and that the stale > option only meant a read didn't have to wait for a current rebuild to > finish. That would means the views are pretty much up-to-date. > > > On Wed, Nov 20, 2013 at 2:36 PM, Robert Newson wrote: > > > True, but remember couchdb doesn't automatically keep indexes fresh in > > the background, so "stale" can be "really really stale". ;) > > > > B. > > > > > > On 20 November 2013 22:34, Simon Metson wrote: > > > Unless your app can deal with querying the view stale. > > > > > > > > > On Wednesday, 20 November 2013 at 21:56, Mark Hahn wrote: > > > > > > > I meant http view requests were blocked. It is waiting for the view > > > > rebuild. > > > > > > > > I'm can't type what I'm thinking today. > > > > > > > > > > > > On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn wrote: > > > > > > > > > never mind. I wasn't talking about the file level at all. I meant that > > > > > http read requests are blocked after http update requests. > > > > > > > > > > > > > > > On Wed, Nov 20, 2013 at 1:52 PM, Robert Newson > > wrote: > > > > > > > > > > > "DB reads are blocked by DB updates at the http level." > > > > > > > > > > > > Nope, there's a process that can read the database and a separate > > one > > > > > > for writing to it. Writing to an append only file is obviously > > > > > > serialized but there's no need to block reads. > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > > > On 20 November 2013 21:35, Mark Hahn wrote: > > > > > > > > Database writes are not coupled to view updates. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I understand now, you are talking about file read/write level. DB > > reads > > > > > > > are blocked by DB updates at the http level. > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2013 at 1:05 PM, Robert Newson < > > robert.newson@gmail.com > > > > > > > wrote: > > > > > > > > > > > > > > > "A write requires updating views and reads have to wait for the > > update" > > > > > > > > > > > > > > > > Is not true. Database writes are not coupled to view updates. > > > > > > > > > > > > > > > > Sent from my iPad > > > > > > > > > > > > > > > > > On 20 Nov 2013, at 20:59, Mark Hahn wrote: > > > > > > > > > > > > > > > > > > A write requires updating views and reads have > > > > > > > > > to wait for the update > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --528d3bad_41a7c4c9_1cb--