jhs

    reduce:function(key, values, rereduce) {
	function addPropertiesTogether(addTo,addFrom){
	    for (var prop in addFrom) {
		(addTo[prop] !== undefined) ? addTo[prop] += Number(addFrom[prop]): addTo[prop] = Number(addFrom[prop]);
	    }
	    return addTo;
	};
	return values.reduce(addPropertiesTogether,{});
    }

jhs

// Prettier case statement, but can also return a value since it is an expression.
//

first_condition
  ? first_action()
: second_condition
  ? second_action()
: third_condition && can && (be || compound)
  ? action_3()
: default_action()

jhs

// Prettier case statement, but can also return a value since it is an expression.
//

first_condition
  ? first_action()
: second_condition
  ? function() {
    var local_var = 'whatever'
    second_action(local_var)
    return whatever_else({you: "want"})

jhs

var request = require('request')
  , db = 'http://localhost:5984/my_db'

request.put(db, function(er, res) {
  // This never happens. You need a body in an options object.
})

request.put({uri:db, body:'blah'}, function(er, res) {
  // This is the normal API. It's fine.
})

jhs

<script type="text/javascript" src="modules.js"></script>
<script type="text/javascript">
    var YUI = require('yui');
    var $ = require('jquery')

    $(document).ready(function() {
       YUI.i.dont.know.the.YUI.API()
       YUI.do_stuff()
    })
</script>

jhs

// Old and busted.
Object.keys(obj).forEach(function (k, _, __) {
  var val = obj[k]
  if (val && typeof val === "object") {
    children.push(k)
  } else {
    out += safe(k) + " = " + safe(val) + "\n"
  }
})

jhs

Conflict winners are chosen dynamically, every time a request for the document arrives. The revision tree is sort of like a git repository: most updates are based on a parent update. In general, you have a tree of changes, but usually it works out to a linear linked list.

Anyway, the winner is the version with the longest revision history. (That is arbitrary but deterministic, so two couches with the same revision trees will pick the same winner.)

couch_doc:to_doc_info_path does the main job: converting the revision tree into an array of paths from root to leaf. It returns this array sorted, with the longest path first. The diff here will print a log message every time the comparison function is called by lists:sort().

The execution path basically goes:

1. couch_http_db:db_doc_req()
2. couch_db:open_doc()

jhs

if(something_happened) {
  // Do stuff because something happened.
  do_stuff()
  do_more_stuff()
}

else if(the_other_thing)
  ; // This situation is fine, but there is nothing to do.

else

jhs

% normalize_path experiments

-define(SEPARATOR, $\/).

main(_) -> ok
    , Paths = [ ""
              , "/"
              , "/foo/bar/baz"
              , "foo/one//two///three////"
              , "foo/bar/..//baz"

jhs

1. Introduction to the replicator database

A database where you PUT/POST documents to trigger replications and you DELETE to cancel ongoing replications. These documents have exactly the same content as the JSON objects we used to POST to /_replicate/ (fields "source", "target", "create_target", "continuous", "doc_ids", "filter", "query_params".

Replication documents can have a user defined "_id". Design documents (and _local documents) added to the replicator database are ignored.

The default name of this database is _replicator. The name can be changed in the .ini configuration, section [replicator], parameter db.

2. Basics