Upgrading to ArangoDB 2.8

Please note first that a database directory used with ArangoDB 2.8 cannot be used with earlier versions (e.g. ArangoDB 2.7) any more. Upgrading a database directory cannot be reverted. Therefore please make sure to create a full backup of your existing ArangoDB installation before performing an upgrade.

ArangoDB will perform a database version check at startup. When ArangoDB 2.8 encounters a database created with earlier versions of ArangoDB, it will refuse to start. This is intentional.

The output will then look like this:

To make ArangoDB 2.8 start with a database directory created with an earlier ArangoDB version, you may need to invoke the upgrade procedure once. This can be done by running ArangoDB from the command line and supplying the option.

Note: here the same database should be specified that is also specified when arangod is started regularly. Please do not run the --upgrade command on each individual database subfolder (named database-<some number>).

For example, if you regularly start your ArangoDB server with

unix> arangod mydatabasefolder

then running

will perform the upgrade for the whole ArangoDB instance, including all of its databases.

The last line of the output should look like this:

2015-12-04T17:12:15Z [31558] INFO database upgrade passed

Please check the full output the --upgrade run. Upgrading may produce errors, which need to be fixed before ArangoDB can be used properly. If no errors are present or they have been resolved manually, you can start ArangoDB 2.8 regularly.

A cluster of ArangoDB instances has to be upgraded as well. This involves upgrading all ArangoDB instances in the cluster, as well as running the version check on the whole running cluster in the end.

We have tried to make this procedure as painless and convenient for you. We assume that you planned, launched and administrated a cluster using the graphical front end in your browser. The upgrade procedure is then as follows:

1. First shut down your cluster using the graphical front end as usual.

2. Then upgrade all dispatcher instances on all machines in your cluster using the version check as described above and restart them.

3. Hit this button, your cluster will be upgraded and launched and all is done for you behind the scenes. If all goes well, you will see the usual cluster dash board after a few seconds. If there is an error, you have to inspect the log files of your cluster ArangoDB instances. Please let us know if you run into problems.

This upgrades the cluster and launches it, exactly as with the button above in the graphical front end. You have to replace "root" with a user name and "" with a password that is valid for authentication with the cluster.

The implementation of the require function used to import modules in ArangoDB and Foxx has changed in order to improve compatibility with Node.js modules.

Given an app/service with the following layout:

• manifest.json
• controllers/
  • todos.js
• models/
  • todo.js
• repositories/
• node_modules/
  • models/
    • todo.js

The file controllers/todos.js would previously contain the following require calls:

var _ = require('underscore');
var joi = require('joi');
var Foxx = require('org/arangodb/foxx');
var Todo = require('models/todo'); // <-- !

The require paths repositories/todos and models/todo were previously resolved locally as relative to the app root.

Starting with 2.8 these paths would instead be resolved as relative to the node_modules folder or the global ArangoDB module paths before being resolved locally as a fallback.

In the given example layout the app would break in 2.8 because the module name models/todo would always resolve to node_modules/models/todo.js (which previously would have been ignored) instead of the local models/todo.js.

In order to make sure the app still works in 2.8, the require calls in would need to be adjusted to look like this: