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 documents. Again, please correct me if i talk rubbish ;) Cheers, > >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 > > >-- >Chris Anderson >http://jchrisa.net >http://couch.io Markus Jelsma - Technisch Architect - Buyways BV http://www.linkedin.com/in/markus17 050-8536620 / 06-50258350
