couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <adam.kocolo...@gmail.com>
Subject Re: 0.9.0 Release
Date Wed, 03 Dec 2008 14:09:51 GMT
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.


Mime
View raw message