On Dec 2, 2008, at 2:29 PM, Damien Katz wrote:
Also, some people have complaints about the programmatic interfaces
for map/reduce/rereduce functionality. If anyone wants to change
these, or any other major aspects of CouchDB interfaces, now is the
time. It only gets harder as we move forward.
Two pieces of the API still feel a little rough to me:
1) Copying identical map functions throughout a design doc. I know
the map is only being executed once if all copies are byte-identical,
so what if we could name map functions in the top level of the design
doc object and then refer to those names in the view definitions?
Perhaps we could make it work for reduce too, so a design doc might
look like
{
"_id":"_design/company",
"_rev":"12345",
"language": "javascript",
"count": "function(keys, values, rereduce) { ... }",
"the_map": "function(doc) { ... }",
"views":
{
"view1": {
"map": "the_map",
"reduce": "count"
},
"view2": {
"map": "the_map",
"reduce": "function(k, v, rered) { ... }"
}
}
}
2) The "/" in the _design doc ID is confusing. I know it's just a
document in a flat namespace like any other and therefore I need to
URL-encode the "/", but to a new user playing with Futon it can look
like CouchDB is really using a nested namespace. I think there could
be an alternative (either promoting _design/ to a proper resource or
maybe using a different delimiter in the design doc ID) that would be
"less surprising". At least I think it's worth another discussion
before the beta.
