Each time a document has been updated or added, the view server is invoked with that document and *all* of the views in a given design. So in some ways, this is a cpu/memory trade off. The 'cpu' being the cost of deserializing the document within the view server. It's done once and the various map functions are invoked with the same document. If your document is fairly large, then this minimizes the cpu cost. But if you have lots of views in the same design document, then the key-values emit'd by your views can suck up lots of memory.
At least that's what I make of it. Maybe the couch creators can comment on this more. BTW, is there a reason why we couch is still using spidermonkey as the only option while v8 has gotten faster and faster? K. --- http://blitz.io http://twitter.com/pcapr On Wed, Mar 23, 2011 at 12:36 AM, Mark Hahn <m...@boutiquing.com> wrote: > I am a newbie, but I don't really understand why the views are divided > into designs in the first place. > > I can understand what a design means intuitively, but can someone > explain what it is good for? I know it is good for solving my > original question, but that is fixing a negative. Is there anything > positive about a design? > > On Tue, Mar 22, 2011 at 10:16 PM, kowsik <kow...@gmail.com> wrote: >> On Tue, Mar 22, 2011 at 9:31 PM, Mark Hahn <m...@elleh.com> wrote: >>>> The recommended way is to add a new design/view (with the change) have >>> CouchDB take its time to index it and then switch over to this view. >>> >>> This solves everything for me. >>> >>>> I had the impression from the discussion that the server blocked more >>>> widely than just the view being generated >>> >>> It does. All views in a design are blocked when you change the >>> source code of one view. I only have one design so that was all views >>> on the server for me. >> >> I go back and forth on this one. To me, it's logical (spoken like >> spock!) to have a design that represents a collection of views that >> are related. This also means that the view server gets handed *all* >> the views in the design for each new/updated document, which makes the >> emit's fast. OTOH, having one view/design means that you can >> change/version a single view without affecting anything else, but the >> overall indexing takes longer. On one project I have one >> view-per-design while on the other it's multiple views-per-design. Go >> figure. I'm still trying to figure out the optimal setting. :) >> >> K. >> --- >> http://blitz.io >> http://twitter.com/pcapr >> >>> >>> On Tue, Mar 22, 2011 at 9:16 PM, Andrew Stuart (SuperCoders) >>> <andrew.stu...@supercoders.com.au> wrote: >>>> Ah well that makes sense. I had the impression from the discussion that >>>> the >>>> server blocked more widely than just the view being generated which would >>>> have been very strange. >>>> >>>> >>>> On 23/03/2011, at 3:12 PM, kowsik wrote: >>>> >>>> On Tue, Mar 22, 2011 at 8:51 PM, Andrew Stuart (SuperCoders) >>>> <andrew.stu...@supercoders.com.au> wrote: >>>>> >>>>> Say I put 100,000 documents into a production database. Is that database >>>>> usable whilst the views are updated to include those new documents? >>>> >>>> The recommended way is to add a new design/view (with the change) have >>>> CouchDB take its time to index it and then switch over to this view. >>>> This way the existing views are super fast and nothing gets blocked. >>>> I'm sure this is in the wiki or the book. >>>> >>>> And yes, the rest of the views are happily available without blocking >>>> while this particular new view is "catching up". >>>> >>>>> What exactly is blocked and under what circumstances? >>>> >>>> Only the access to the new view which is getting indexed. Nothing else >>>> blocks. >>>> >>>> K. >>>> --- >>>> http://blitz.io >>>> http://twitter.com/pcapr >>>> -- >>>> Message protected by MailGuard: e-mail anti-virus, anti-spam and content >>>> filtering.http://www.mailguard.com.au/mg >>>> Click here to report this message as spam: >>>> https://login.mailguard.com.au/report/1BXm6do62R/6XbNWx99CirvTmBxZ7aJxt/0 >>>> >>> >> > > > > -- > Mark Hahn > Website Manager > m...@boutiquing.com > 949-229-1012 >
