From user-return-5492-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Jul 10 20:29:28 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 66189 invoked from network); 10 Jul 2009 20:29:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Jul 2009 20:29:27 -0000 Received: (qmail 32001 invoked by uid 500); 10 Jul 2009 20:29:36 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 31916 invoked by uid 500); 10 Jul 2009 20:29:36 -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 31906 invoked by uid 99); 10 Jul 2009 20:29:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jul 2009 20:29:36 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com designates 209.85.210.204 as permitted sender) Received: from [209.85.210.204] (HELO mail-yx0-f204.google.com) (209.85.210.204) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jul 2009 20:29:25 +0000 Received: by yxe42 with SMTP id 42so1930670yxe.13 for ; Fri, 10 Jul 2009 13:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=Y1KHG2t81toVXN5hXi0Rk8COANSRo/9mtU7R2q2JxAA=; b=SLZ4w9K96wAHX04PkOeJum/vVssd4ddFEEnc4tHQ5HO7wb66nXtbDVXQnHhgUsOvew TAc6emU8PjZwJhfuoPjt9su0JuMEgPAjffhbG0Ug0/vQl2DYdzyAiL/0AdzCIMcI1qab DGUh3L7pZOflGzKx6XbUPP63D4O4ZzU0lUk3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=rgnSv8RPpIA/bmBnd096Jo4gmO/9TWwrLMuS/AJOFx/IJykv8GZyrMhHis3YslAGBh 5NrRyafvYMA/c9gKQRSTR4iOSkUm32xEAFYpCE+J6Ck9en1EZ00M5iN5vo8MMFRFZY6W MJTb7OdREIII9cy3glMVM0BQLDEHFQkSSirDQ= Received: by 10.90.79.17 with SMTP id c17mr1969563agb.58.1247257744192; Fri, 10 Jul 2009 13:29:04 -0700 (PDT) Received: from ?10.0.1.2? (c-71-232-49-44.hsd1.ma.comcast.net [71.232.49.44]) by mx.google.com with ESMTPS id 20sm3963382agd.23.2009.07.10.13.29.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 13:29:03 -0700 (PDT) Sender: Adam Kocoloski Message-Id: From: Adam Kocoloski To: user@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Updating views in a production system Date: Fri, 10 Jul 2009 16:29:01 -0400 References: <8ffb00ae0906082313j798fe874u3925cfd75de562ac@mail.gmail.com> <2F5EA1F1-03E0-4714-AE50-05AA3A70CA05@apache.org> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org On Jul 10, 2009, at 4:19 PM, Chris Anderson wrote: > On Fri, Jul 10, 2009 at 11:47 AM, Zachary > Zolton wrote: >> Argh... accidentally hit "send" too soon~!! >> >> Awesome, but since I'm still using 0.9 in production, I'll need to do >> something else in the meantime. >> >> Will stale=ok queries remain performant during the re-indexing >> imposed >> by pushing an updated design document? >> >> If that's gonna work for me, I'll probably change my deployment >> strategy to the following: >> 1) flip the "latency" switch on, in a admin page >> 2) now all queries use stale=ok >> 3) push our new design documents >> 4) "prime" a view for each design document >> 5) somehow know when the indexing has finished >> 6) flip the "latency" switch off >> 7) now queries should go to the freshly-built indexes! >> >> Does anyone see glaring problems with this approach? >> > > You can simplify: > > users hitting _design/foo/_view/bar > > upload new ddoc to _design/fooX > > query view at _design/fooX/_view/bar once to trigger generation > > when it's done, http COPY _design/fooX to _design/foo > > users querying _design/foo/_view/bar should never see downtime > > (let me know if this works it's based on a new feature I just added) But Zach's looking for something that works in 0.9. And Zach, I'm afraid your plan won't work there. In my experience your stale=ok queries will return 0 rows after you upload the new design doc. Best, Adam