Impedance mismatch with CouchDB | Hacker News Reader

Impedance mismatch with CouchDB

brehaut.net

27 pointsmattdw11 comments

Arc90's "Readability" to the rescue, it seems.

Seriously, who in the world thought that site's color scheme was reasonable?

On Windows, Mac, or Linux? I don't find it too bad, but I suspect it's one of those color schemes that is greatly monitor/OS/color-calibration sensitive.

I disagree. For any form of long-form text, black on white or black on grey is generally the best way to go. Focus on the writing, not the color scheme.

Some good points in here about the tradeoffs you make with Couch. One I didn't quite understand:

"For instance I cannot have a view that filters out fragments that have publish dates in the future."

Isn't this as simple as ?startkey=0&endkey=[now] ?

That requires date information to be in the keys of all the views. Some of my views are not chronologically keyed, but i would still like them to have items that i intend to have be published in the future not accessible. I would like to avoid that sort of accidental complexity.

The other issue is that it splits the 'is this a visible fragment' logic across the db and application code boundary. I now have to ensure that all the appropriate checks are in place in two layers rather than one.

isn't this the kind of thing that filtered replication is designed to handle?

I've not looked into that at all. Thanks for the pointer

"Views only operate on the original pool of documents, and are not able to be a view of views."

The inability to chain map/reduce calls is the biggest thing holding CouchDB back, particularly w.r.t. CouchApps that don't have the luxury of an easy workaround. There is a bug https://issues.apache.org/jira/browse/COUCHDB-249 however no progress has been made recently.

By allowing views on the output of other views, more "normalized" document structures could exist that would still be transformable into useful outputs.

Cloudant has a very cool couchdb fork that uses a dynamo style k/v layer that then uses couchdb as its storage engine. They implement chained map/reduce with the caveats that A) the chained m/r is generated async, so it is always out of data a bit and B) I never got it working in their hosted product. I checked them out for the chained M/R but was really wowed by the scale out capable with their system. The dynamo layer takes care of sharding, migrating shards, re-reducing parallel queries etc.

"On the up side, you don’t ever have to manage indexes; Couch is smart enough to determine these for you." and "In place of the familiar queries, Couch supports the definition of Views."

Views aren't really synonymous with queries; they're conceptually closer to indexes: They rearrange the data in such a way that allows certain types of queries to be fast.

So in reality, you are forced to manage your indexes (views) in CouchDB.

Red text on yellow background. I wish HN had a downvote button.

Reply on news.ycombinator.com