couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1270) Rewrite the view engine
Date Tue, 06 Sep 2011 16:10:11 GMT


Paul Joseph Davis commented on COUCHDB-1270:


Bit confusing with these in close proximity. The function calls to link/unlink are just the
Erlang process links. Ie, "we stop caring about the old fd, and only want to know about the
new fd. Just below that is the rename-delete/rename dance dealing with filesystem links. This
is the same behavior as trunk where it is possible that we lose the compacted file with a
well timed crash. Trunk still doesn't address this and I haven't spent time thinking through
all of the edge cases picking up a compaction file if the main data file is gone. Suffice
to say, behavior is the same for that switch but we haven't figured out the best way to make
that more robust (though, I don't know of a single report where this broke and caused reindexing).

As to variable naming, it looks like you knew what they all meant. mrst could use some documentation
just because its so core to the m/r indexer. Also, most of these are internal and shouldn't
be user visible which means that their context is well defined within the relevant code.

Also, dropping the d from http was quite intentional. I mean, why is the d there to begin

> 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