On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke <[email protected]> wrote:
> > On Aug 15, 2013, at 10:14 AM, Jason Smith <[email protected]> wrote: > > > To restate my final sentence which you quoted: Accessing a view is an > index > > scan, it hardly matters what the total data size is; therefore after the > > building period, all views are basically always instantly available. > > You’re missing my point, Jason. Introducing an arbitrary “building period” > implies you don’t care about the latency between a database update and when > it becomes visible in view queries. As I said, that may be allowable in > some types of applications, but definitely not all. To repeat my example, > an e-commerce customer is not going to tolerate any “building period” > longer than a second or two in between their clicking “Add To Cart” and the > item showing up in their cart. > I agree. But a hypothetical "Add to cart" would only be one or two document updates. That will be reflected in a view query pretty quickly. The HTTP overhead is probably still the majority of the time spent; updating the view index to reflect the new cart will be negligible. Do we agree there? It occurs to me that you and I may work in different environments. Perhaps you are accustomed to much heavier update frequency than I. My own glossary: View build time: Building the views the first time you push a new design document into an existing database. Can take a very long time, but can be done "offline." View update time: The time it takes couch to update a view to reflect those updates which happened since either the view build, or the view update (whichever was more recent). To me, view update time is regrettable but for most applications (read-heavy) it is not much of a problem. View build time is not a concern because you can run it at your leisure and "promote" it to the true document ID using COPY. In most situations, native views solve a non-problem (although I've cited a few cromulent exceptions.)
