Docker without sudo, network issues posted on 05 September 2015

If you want to run docker without using sudo, you can add yourself to the docker group.

sudo usermod -aG docker <user>

In my case (Archlinux), this was not quite enough. Starting a container would work but without internet access. The main problem was that I was not part of the network groop.

sudo usermod -aG network <user>

Then things went smoothly.

Losing connectivity after a Chrome request posted on 30 August 2015

When I upgraded my kernel from 4.0.7-2 to (and more recently to 4.1.6-1) I had a really annoying bug and since it wasted some of my time, I hope that this post may help someone.

After my 4.1 kernel update, I would start connected to the internet. I could ping any server, use wget, but as soon as I would make a request on Chromium or Firefox, I would "lose connectivity" after a few seconds. By loosing connectivity, the pings would timeout or fail with "Destination Host Unreachable". Once of the reason I had a hard time finding the reason is that I had no errors reported by the kernel or the driver. The only way to get back a connectivity was to take down the interface and bring it back up.

Eventually, everything boiled down to my Qualcomm Atheros AR8161 driver. Increasing the MTU to 9000 fixed my problem as described on this archlinux bug

Rethinkdbdash and client side backtraces posted on 15 August 2015

A bit of context

I released rethinkdbdash 2.1.3 (and 2.1.4) a bit earlier today. This release besides adding a few missing syntaxes for 2.1 (r.union and condition.branch(...)), fixed an issue with the client-side backtraces, though to be honest, the client-side backtraces were not really working before.

If a RethinkDB query throws an error, the server will provide a backtrace and the driver will reconstruct the query and underline the broken part. For example if a table is missing you will see this error:

ReqlOpFailedError: Table `test.users` does not exist in:
r.db("test").table("users").filter(function(var_1) {
    return var_1("age").gt(18)

The query is printed back and the broken parts are highlighted. These backtraces are in my opinion of the little one of the little things that makes RethinkDB enjoyable to use. However a few queries cannot be sent to the server and therefore no backtraces are available. Because RethinkDB stores JSON document, some JavaScript values are forbidden, typically NaN and Infinity. When the driver finds a forbidden value, it used to just throw an error saying NaN cannot be converted to JSON. This is painful for two reasons:

  • The presence of NaN is an operational error and the driver should just reject the query, not throw.
  • NaN can easily propages and you basically have to inspect all possible variables. The bigger your query, the harder debugging it is.

What's new

Since 2.1.3, Rethinkdbdash now builds backtraces for these errors and will point exactly where the problem is.

var r = require('rethinkdbdash')();

var ADULT_AGE = 18;
var ADULT_AGE_US = NaN; // oops

r.db('test').table('users').merge(function(user) {
  return r.branch(
    { canDrink: user('age').gt(ADULT_AGE_US) },
    { canDrink: user('age').gt(ADULT_AGE) }
}).run().then(console.log).error(function(error) {

What will be printed is:

ReqlRuntimeError: Cannot convert `NaN` to JSON in:
r.db("test").table("users").merge(function(var_1) {
    return r.branch(var_1("location").eq("US"), {
        canDrink: var_1("age").gt(NaN)
    }, {
        canDrink: var_1("age").gt(18)

Pretty cool uh? You can pin exactly where the NaN value is.

Feedback/suggestions? Ping me on Twitter via @neumino or shoot me an email at [email protected].

Thinky 2.1.1 - Updating only relations posted on 13 August 2015

I released thinky 2.1.1 a bit earlier today.

Thinky was built on the assumption that you always retrieve all the documents from the database because updating a relation. Typically this was the expected workflow.

var thinky = require('thinky')();
var type = thinky.type();

User = thinky.createModel("User", {
  id: type.string(),
  email: type.string().required(),
  name: type.string().required(),
  adult: type.boolean().default(false)

User.hasAndBelongsToMany(User, "friends", "id", "id");

    .getJoin({friends: true}).run().then(function(user) {
  // user is fully defined with its friends
  user.friends = [];
  return user.saveAll({friends: true});
}).then(function(user) {
  // user 3851d8b4-5358-43f2-ba23-f4d481358901 has no more friends!

Looking at the GitHub issue tracker, many developers had issues. Trying to save a relation with pre-existing documents can throw errors like #245 and basically wasn't clear for many #309. Thinky 2.1.1 takes a stab at all these problems and introduces two new commands:

 - addRelation(field, joinedDocument)
 - removeRelation(field[, joinedDocument])

You can chain these commands on a query that returns one document and add/remove a relation.

Example: Add a new friend

User.hasAndBelongsToMany(User, "friends", "id", "id");

    .addRelation('friends', {id: '0e4a6f6f-cc0c-4aa5-951a-fcfc480dd05a'})

Example: Remove a new friend

    .removeRelation('friends', {id: '0e4a6f6f-cc0c-4aa5-951a-fcfc480dd05a'})

Example: Remove all friends


The second argument to addRelation needs to provide just enough information to create a relation.

  • In the case of a hasOne or hasMany relation, only the primary key is required.
  • In the case of a belongsTo or hasAndBelongsToMany relation, the primary key or the right key is required - one is enough!

The same argument for removeRelation is not always required and if it is defined, it also needs just enough information to find the relation to delete.

  • For hasOne and belongsTo relations, the joinedDocument is not required and should not be provided.
  • For hasMany and hasAndBelongsToMany relations, the absense of the joinedDocument makes the command delete all the relations for the given document. If a document is provided, the primary key or the right key is required - again, one of them is enough.

This update should enable people easier to manipulate relations without the need to retrieve the documents from the database. Beyond a simpler interface, it should also ease a little the load on the database.

Feedback/suggestions? Ping me on Twitter via @neumino or shoot me an email at [email protected].