couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Jelsma <>
Subject Re: M/R/M, again
Date Thu, 28 Jan 2010 11:44:47 GMT
Hi Chris,

Thanks for your reply. I see that this might work indeed, after giving it some 
more thought, but i think i have a few issues with such an approach. It would 
fill the database with data i don't want/need and replication would also copy 
this extraneous data. Secondly, i cannot simply construct a view that can 
operate on the data at hand for i would then need to construct a view that 
operates on previously copied data, is it not?

I believe, but am not entirely sure, that i would then prefer to use the 
tricks as described in the wiki.

What is the issue with added the merge feature to the Couch? Is it extremely 
hard to do so? I'd figure the resulting view with still fit in the BTree as it 
does now, but correct me if i'm wrong :)

I understand people are fine with Hadoop offering batch processes instead but 
it still sounds a bit funky for CouchDB, which is still so clean and neat and 
would, in my opinion, benefit since it would be easier to query for related 

Again, please correct me if i talk rubbish ;)


>There are a number of ways things like this could be accomplished. One
>I proposed recently is the facility to have CouchDB automatically copy
>any  http view query result (local or remote) to a database full of
>documents (one document for each row). This gives you a lot of
>flexibility, but it is not incremental.
>I think it's ok if it's not incremental. Hadoop is a batch process,
>and people are fine with that.
>The cool thing about this is it's in the HTTP domain so it will work
>on a cluster, can be cached, etc.
>Chris Anderson

Markus Jelsma - Technisch Architect - Buyways BV
050-8536620 / 06-50258350

View raw message