Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of siriele2x3@gmail.com designates
 74.125.83.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACLy94Vf6TOz80cM_gWn26nFvMe8A4uQwQNNZQSBRBgYzXB9zg@mail.gmail.com>
References: 
 <CAPNuaCjQ3wgAd1BMyNUtip0rztK6n3Ex3rnq-hc=NXwL4Wt+pg@mail.gmail.com>
	<CAG+HO1ysanHLAYTh5XXuN=WO3RMsjxsY9c5nXjGiHy1n_m74mA@mail.gmail.com>
	<CAPNuaCjTS1+GAqx=WG0qjiP+3Rc06bXbSFDc9jdvHOOZwWY+3g@mail.gmail.com>
	<CAG+HO1x+L2rKTXaVcuu2_n0FQW_5CWZ7Jk5qo96-8OK-sRU7XA@mail.gmail.com>
	<CAPNuaCh5qK2YxS0txBicvrc4fnQCgrj5pVz=_M0xqXaKfQyYjg@mail.gmail.com>
	<CAG+HO1w+N_TxeroFpKwY+U=G2iC6eEU2QMDbV9aGgueDsZ5Bcg@mail.gmail.com>
	<CACLy94Uq9eafd_Q-LXV8b3aCipnHgMnaWdn2C1LjnvuMQ-csiA@mail.gmail.com>
	<CAG+HO1zySzJyQMnSj9hfeHVR-XNB2Hpqr97A5ugabvo-wGKdXg@mail.gmail.com>
	<CACLy94XLwHcDyP12igsvCPJ5p46=3=HdoW3xAz_+2RgXH6s=pA@mail.gmail.com>
	<CACLy94Vf6TOz80cM_gWn26nFvMe8A4uQwQNNZQSBRBgYzXB9zg@mail.gmail.com>
Date: Wed, 14 Aug 2013 23:36:25 -0700
Message-ID: 
 <CAPNuaCiQV2xoDj2O5vg+a-pDzj5ywCwmc+To16ybLeUh4Uc4eA@mail.gmail.com>
Subject: Re: Erlang vs JavaScript
From: Stanley Iriele <siriele2x3@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b60399c78567904e3f6b1bb

--047d7b60399c78567904e3f6b1bb
Content-Type: text/plain; charset=ISO-8859-1

Wait....I'm a tad confused here..Jason what is the difference between
native views and Erlang views?...
On Aug 14, 2013 11:16 PM, "Jason Smith" <jhs@apache.org> wrote:

> Oh, also:
>
> They are **not** Erlang views. They are **native** views. We should
> emphasize the latter to remind ourselves about the security and reliability
> risks which Bob identifies.
>
> They are very powerful, but it is a trade-off. Once I had a customer who
> had a basic "class" document describing common values. All other documents
> were for modifications to the "base class" so to speak. He needed to query
> by document ID, but if no such document existed, return the "base class"
> document instead. The product was already in the field and so the code
> could not change. We had to change it in CouchDB.
>
> The fix was very simple: a _rewrite rule to a native _show function. In the
> show function, if the Doc was null, then we used the internal CouchDB API
> to fetch the default document. Voila.
>
>
> On Thu, Aug 15, 2013 at 1:08 PM, Jason Smith <jhs@apache.org> wrote:
>
> > On Thursday, August 15, 2013, Andrey Kuprianov wrote:
> >
> >> Doesnt server performance downgrade, while views are being rebuilt? So
> the
> >> faster they are rebuilt, the better for you.
> >
> >
> > If my view build would degrade total performance to cross an unacceptable
> > threshold, then I am really riding the line! What about an unplanned
> > compaction? What if one day the clients have a bug and load increases?
> What
> > if an unplanned disaster happens and a backup must be performed urgently?
> >
> > I would evaluate view performance in the larger context of the entire
> > application life cycle.
> >
> > Men seem to want to date beautiful women. It is a very high priority at
> > the pub or whatever. But long-married men do not even think about their
> > wife's attractiveness because that is a small, superficial part of a much
> > larger story.
> >
> >
> >>
> >> Besides, looks like it's possible to do the same 3 steps with design doc
> >> views created in Erlang? Or is it just about using require() in Node.js?
> >>
> >
> > Actually, yes that is a fine point. I myself prefer Node.js but anyone
> can
> > choose the best fit for them.
> >
> > And speaking more broadly, CouchDB is a very flexible platform so it is
> > quite likely that my own policies do not apply to every use case. In fact
> > if I'm honest I use native views myself, usually for unplanned
> > troubleshooting, I want to find conflicts so I use manage_couchdb:
> > http://github.com/iriscouch/manage_couchdb
> >
> > My main point is, anybody time somebody says "performance" ask yourself
> if
> > it is really a "performance siren." Earlier in this thread, Jens raises
> > some examples of plausible true performance requirements, not just siren
> > songs.
> >
>

--047d7b60399c78567904e3f6b1bb--