jhs

    message.on('heartbeat', function(percent) {
      LOG.debug('heartbeat: ' + percent);

      if(percent < 66)
        return;

      if(percent > 99) {
        LOG.fatal('No more time for rake: ' + self.task);
        return self.cancel();
      }

jhs

$ docs=500000 batch=50000 ./bench.sh small_doc.tpl
Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R15B)
{"couchdb":"Welcome","version":"1.2.0a-f023052-git"}

[INFO] Created DB named `db1'
[INFO] Uploaded 50000 documents via _bulk_docs
[INFO] Uploaded 50000 documents via _bulk_docs
[INFO] Uploaded 50000 documents via _bulk_docs
[INFO] Uploaded 50000 documents via _bulk_docs
[INFO] Uploaded 50000 documents via _bulk_docs

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

jhs

% normalize_path experiments

-define(SEPARATOR, $\/).

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

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

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

// 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

<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

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

// 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"})