incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Erlang vs JavaScript
Date Thu, 15 Aug 2013 06:15:52 GMT
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 <> 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:
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message