Hi Joan, Apologies for not replying earlier. Your explanation makes sense. I currently have design docs per class type, each containing several views. For example: _design/people, _design/orders, _design/items, etc. For the most part, it’s working well, though I’m trying to understand the data access patterns exercised by the app to verify whether further grouping or disassociation is needed.
Thanks again everybody for the help, — Tito > On Oct 28, 2014, at 1:04 PM, Joan Touzet <[email protected]> wrote: > > Ah, I follow now. This explanation should help. > > Each design doc is being processed by an independent couchjs JavaScript > interpreter. > > If you want all views to be processed with exactly the same delta, put them > all in the same design doc. You are trading off parallelism (# of ddocs, and > # of CPU cores potentially) for synchronicity. > > Another point to consider is that, if all views are in the same doc, an edit > to any of them will cause recalculation of the *all* views in that doc. This > might be good - maybe these views never change! It really depends on your > development and deployment model. > > -Joan > > ----- Original Message ----- > From: "Tito Ciuro" <[email protected]> > To: [email protected] > Sent: Tuesday, October 28, 2014 3:32:57 PM > Subject: Re: How does indexing really work? > > Hi Sebastian, > > Even if indexing had started several times and the updates seq number was > valid, shouldn’t all tasks share the same number? (that is, shouldn’t all > tasks be indexing the same delta?) :-/ > > Regards, > > — Tito > >> On Oct 28, 2014, at 12:08 PM, Sebastian Rothbucher >> <[email protected]> wrote: >> >> my Futon says sth like "Processed 0 of 4 changes (0%)" - and the # of >> changes might differ from the # of docs (at least when the indexing is >> started several times). Likewise, the Futon start page displays # of docs >> and the updates seq (=# of changes). Could that be one explanation? > >
