couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: incremental map/reduce scope
Date Wed, 26 Mar 2008 03:23:15 GMT

On Mar 25, 2008, at 23:05 , Sho Fukamachi wrote:
> Thanks for the responses Chris and Jan.
> That's pretty much exactly what I thought - I just wanted to clear  
> it up!
> The reason I asked was because I've seen what I consider to be some  
> not-very-good practise in some interface programs for Couch. For  
> example, in ActiveCouch, databases are treated basically like tables  
> - it seems to imply one should create a database called "people",  
> for example, and then another one called "blogs". This seemed to me  
> to be a pretty bad idea - trying to force CouchDB into a very RDBMS- 
> shaped hole, so I was wondering if they knew something I didn't  
> about the present or future scope of "map" - evidently not. I am not  
> sure how prevalent this kind of thinking is but evidently it needs  
> to be discouraged.

Ouch. It certainly does. ActiveCouch should reconsider
and use views instead of databases. One of the key features
of CouchDB is the schemaless storage of messy data in one
database and make sense of it via views.

>> [...]
>> With the possibility of using other languages for the M/R functions,
>> you could, for example, use Python to run the functions and from
>> within the functions use an HTTP request to get data from another
>> DB. If you really wanted that. I'd guess though that you'd be better
>> off with using a database merge with replication or implementing
>> things on the application level. I might be wrong, though :)
> Ha, that sounds like a nightmare! I don't think anyone should be  
> thinking about that kind of thing except as a last resort.

Yeah, it'd be hard to guarantee the referential transparency
that map functions require. Anyway.

> I guess the scenario I thought could be possible was that design  
> docs could be definable at the root level of the server, above the  
> databases, and then look into all docs in all databases. It's no  
> surprise, though, that this isn't done - there would be no advantage  
> beyond a superficially more pleasant namespace.

With the new architecture that separates views from storage
this might even be possible. Damien? It might be useful for
administrative tasks.

> Has the community arrived at a kind of "best practise" for  
> differentiating between record types? In the wiki using the key  
> "type" is suggested, I am wondering how official this is. Not that  
> it needs to be official, of course, but establishing some sort of  
> convention is probably a good idea to get everyone on the same page.

We started using "type" or "Type" sort of as a convention because
we wanted to encourage a de-facto standard for programming
CouchDB. This worked well so far and we couldn't find any
problems. But I guess not much thinking went into it, so we
still might regret that at some point. So, if you (anyone) can
think of problems (and present a better solution), please
speak up.

> If it is, what might be nice would be to promote "type" in a doc to  
> a reserved magic word like _id or _rev. A built-in function to get  
> "all documents by type" and/or present a list of filterable types in  
> the web interface would perhaps help make the database more  
> approachable to RDBMS refugees and help encourage people towards  
> understanding document-based data structures, and away from the  
> table-based mentality. Just a thought.

I had that exact idea too, but dismissed it. This is not
inherent to CouchDB and thus shouldn't be part of
the API. As far as documenting things goes, if we all
use "type" or "Type" in our examples, people will pick
this up just as well.


View raw message