[Couchdb Wiki] Update of Introduction to CouchDB views by BrianCandler

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Couchdb Wiki for 
change notification.

The following page has been changed by BrianCandler:
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views

The comment on the change is:
Add some links and a stronger restriction on reduce/rereduce processing

--
  
  For more details see [http://damienkatz.net/2008/02/incremental_map.html this 
blog post]
  
+ Furthermore: you have no control over how documents are partitioned in reduce 
and re-reduce phases. You cannot rely on adjacent documents all being 
presented at the same time to the reduce function; it's quite possible that one 
subset will be reduced to R1, another subset will be reduced to R2, and then R1 
and R2 will be re-reduced together to make the final reduce value. In the 
limiting case, consider that each of your documents might be reduced 
individually and that the reduce outputs will be re-reduced together (which 
also may happen as a single stage or in multiple stages)
+ 
+ So you should also design your reduce/re-reduce function so that
+ 
+ {{{
+ f(Key, Values) == f(Key, [ f(Key, Value0), f(Key, Value1), f(Key, Value2), 
... ] )
+ }}}
+ 
  === Reduced Value Sizes ===
  
  As CouchDB computes view indexes it also calculates the corresponding reduce 
values and caches this value inside each of the btree node pointers. This 
scheme allows CouchDB to reuse reduced values when updating the btree. This 
scheme requires some care to be taken with the amount of data returned from 
reduce functions.
@@ -225, +233 @@

  
  See [http://labs.mudynamics.com/2009/04/03/interactive-couchdb/ this blog 
posting] for an interactive tutorial (emulator in JavaScript) that explains 
map/reduce, view collation and how to query CouchDB RESTfully.
  
+ == Implementation ==
+ 
+ These blog posts include information about how map/reduce works, including 
how reduce values are kept in btree nodes.
+  * [http://damienkatz.net/2008/02/incremental_map.html]
+  * [http://damienkatz.net/2008/02/incremental_map_1.html]
+  * [http://horicky.blogspot.com/2008/10/couchdb-implementation.html]
+ 
+ These mailing list posts may also be helpful:
+  * 
[http://mail-archives.apache.org/mod_mbox/couchdb-user/200903.mbox/20090330084727.ga7...@uk.tiscali.com]
+  * 
[http://mail-archives.apache.org/mod_mbox/couchdb-user/200906.mbox/20090621202105.ga1...@uk.tiscali.com]
+ 

[Couchdb Wiki] Update of Introduction to CouchDB views by BrianCandler

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Couchdb Wiki for 
change notification.

The following page has been changed by BrianCandler:
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views

--
  
  See HttpViewApi to learn how to work with views. [View_Snippets] contain a 
few examples.
  
- == Restrictions on map and reduce functions ===
+ == Restrictions on map and reduce functions ==
  
  The restriction on map functions is that they must be referentially 
transparent. That is, given the same input document, they will always emit the 
same key/value pairs. This allows CouchDB views to be updated incrementally, 
only reindexing the documents that have changed since the last index update.
  
  To make incremental Map/Reduce possible, the Reduce function has the 
requirement that not only must it be referentially transparent, but it must 
also be commutative and associative for the array value input, to be able 
reduce on its own output and get the same answer, like this:
  
+ {{{
  f(Key, Values) == f(Key, [ f(Key, Values) ] )
+ }}}
  
  This requirement of reduce functions allows CouchDB to store off 
intermediated reductions directly into inner nodes of btree indexes, and the 
view index updates and retrievals will have logarithmic cost. It also allows 
the indexes to be spread across machines and reduced at query time with 
logarithmic cost.