couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lehnardt (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1270) Rewrite the view engine
Date Thu, 08 Sep 2011 13:06:09 GMT


Jan Lehnardt commented on COUCHDB-1270:


I understood link/unlink to be the Erlang versions, not the POSIX versions, but was still
curious about the order. Thanks for clarifying that this is like it is today.

For the variable naming, while I was able to figure out what it means, the cognitive extra
load didn't help understanding the code. I'm an advocate of erring not he side of clearness.
I don't buy the 'internal code" argument as my future self will have to jump into that code
again some time in the future and I'm trying to make this easier for myself later. I understand
that coming right out of the code after writing it makes it all obvious, but that's usually
not a long term property and it is only in your head. That said, not a blocker, happy to "clean
that up" later, but I fugue I raise this "while we are at it" :)

As for the "d", that's from the old days when we used the httpd that ships with Erlang and
CouchDB was an (think Apache httpd) mod_couch module and the callback module was called couch_httpd.erl.
So yay, ancient history, lets nuke that d.


> Rewrite the view engine
> -----------------------
>                 Key: COUCHDB-1270
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: JavaScript View Server
>            Reporter: Paul Joseph Davis
>         Attachments: 0001-Minor-changes-for-new-indexing-engine.patch, 0002-Create-the-couch_index-application.patch,
0003-Create-the-couch_mrview-application.patch, 0004-Remove-the-old-view-engine.patch
> The view engine has been creaky and cluttered. As shown by GeoCouch, adding new indexers
basically involves copying the entire view engine and hacking the parts that are different.
In short, the opposite of good engineering.
> Over the last couple weeks I've refactored the view engine and reimplemented the map/reduce
view engine. These changes are 100% internal and no external behavior has changed. Performance
is just a tiny bit better than trunk. I did do some playing trying to improve view update
times and there are some dances we could do, but for the time being I wanted to keep the same
general architecture for updates so that the changes are minimal.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message