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 C63C147B6 for ; Tue, 5 Jul 2011 21:44:55 +0000 (UTC) Received: (qmail 29917 invoked by uid 500); 5 Jul 2011 21:44:54 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 29881 invoked by uid 500); 5 Jul 2011 21:44:53 -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 29873 invoked by uid 99); 5 Jul 2011 21:44:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jul 2011 21:44:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.214.52] (HELO mail-bw0-f52.google.com) (209.85.214.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jul 2011 21:44:48 +0000 Received: by bwj24 with SMTP id 24so7986549bwj.11 for ; Tue, 05 Jul 2011 14:44:26 -0700 (PDT) Received: by 10.204.37.141 with SMTP id x13mr609509bkd.116.1309902266156; Tue, 05 Jul 2011 14:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.3.138 with HTTP; Tue, 5 Jul 2011 14:44:06 -0700 (PDT) In-Reply-To: References: From: Mark Hahn Date: Tue, 5 Jul 2011 14:44:06 -0700 Message-ID: Subject: Re: few doubts To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=bcaec553fda243c6b104a7596333 --bcaec553fda243c6b104a7596333 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cool. That is much easier. Still a bit of a pain. It would be nice if it did this automatically on every view change. On Tue, Jul 5, 2011 at 2:31 PM, Sean Copenhaver wrote: > CouchDB actually relates a design document to it's views by I believe a > hash > of the design document contents (not the id). The wiki actually has a how > to > for deploy view changes in a live environment: > > > https://wiki.apache.org/couchdb/How_to_deploy_view_changes_in_a_live_envi= ronment > > On Tue, Jul 5, 2011 at 5:17 PM, Mark Hahn wrote: > > > > With CouchDB, all you have to do is to create your view within a desi= gn > > document and it will on its own build the actual "indices" (the views) > the > > very first time that those views are actually being used. The next tim= e > > that those views are used, then only newly created and/or updated docs > need > > to be indexed. > > > > Actually, if you change a view in the design doc it rebuilds ALL views = in > > that doc from scratch for ALL documents. This was a surprise to me the > > first time it happened because my entire application froze up for sever= al > > minutes. I can imagine it happening for an hour with a giant db. The > only > > way I can figure out how to get around this problem is to create a seco= nd > > db, sync the main db to the second, rebuild the views on the second and > > then > > overwrite the main db file with the second db file. Kind of a pain. > > > > On Tue, Jul 5, 2011 at 11:17 AM, Randall Leeds > >wrote: > > > > > I like everything you've said in these last three messages which were > > > meant to be one. :) > > > You should make it a blog post. For real. > > > > > > On Tue, Jul 5, 2011 at 00:32, Zdravko Gligic > wrote: > > > > oh, i hate gmail, as it seems to react to certain key combinations > ... > > > > > > > > Focus - It seems that CouchDB has been purposely designed with > "single > > > > mindedness in mind". The approach seems to be that it can be most > > > > efficient if its various functions and its various tasks do small > > > > amounts of work in the most efficient way possible. So, it would > seem > > > > that writes keep on writing to the end of file, instead of flipping > > > > through it and trying to over-write and update in place existing > docs. > > > > Again, in order to be as efficient as it can be with those writes, > it > > > > foregoes updating the views (the same way that an RDBMS would updat= e > > > > all of the related indices as part of its record update) and leaves > it > > > > for another process which will concentrate on doing just that. So, > it > > > > seems that "context switching" or not having to do much of such > > > > switching is where it gets lots of it processing efficiency. > > > > > > > > Again, I am most anxious to see how my noob understandings check ou= t > > > > with technical realities. ;) > > > > > > > > HTH, > > > > teslan > > > > > > > > > > > > > -- > =93The limits of language are the limits of one's world. =93 -Ludwig von > Wittgenstein > --bcaec553fda243c6b104a7596333--