

Impedance mismatch with CouchDB - mattdw
http://brehaut.net/blog/2010/couch_impedance

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

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

~~~
mattdw
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.

~~~
quanticle
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.

------
jdminhbg
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] ?

~~~
brehaut
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.

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

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

------
pixelcort
"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.

~~~
eldenbishop
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.

------
meatmanek
"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.

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

