Manifest

Many of the fields that were required in ArangoDB 2.x are now optional and can be safely omitted.

To avoid compatibility problems with future versions of ArangoDB you should always specify the engines field, e.g.:

  1. {
  2.   "engines": {
  3.     "arangodb": "^3.0.0"
  4.   }
  5. }

Controllers & exports

Previously Foxx distinguished between exports and controllers, each of which could be specified as an object. In ArangoDB 3.0 these have been merged into a single main field specifying an entry file.

The easiest way to migrate services using multiple exports and/or controllers is to create a separate entry file that imports these files:

Old (manifest.json):

  1. {
  2.   "exports": {
  3.     "doodads": "doodads.js",
  4.     "dingbats": "dingbats.js"
  5.   },
  6.   "controllers": {
  7.     "/doodads": "routes/doodads.js",
  8.     "/dingbats": "routes/dingbats.js",
  9.     "/": "routes/root.js"
  10.   }
  11. }

New (manifest.json):

  1. {
  2.   "main": "index.js"
  3. }

New (index.js):

  1. 'use strict';
  2. module.context.use('/doodads', require('./routes/doodads'));
  3. module.context.use('/dingbats', require('./routes/dingbats'));
  4. module.context.use('/', require('./routes/root'));
  5. module.exports = {
  6.   doodads: require('./doodads'),
  7.   dingbats: require('./dingbats')
  8. };

Index redirect

If you previously did not define the defaultDocument field, please note that in ArangoDB 3.0 the field will no longer default to the value index.html when omitted:

Old:

  1. {
  2.   // no defaultDocument
  3. }

New:

  1. {
  2.   "defaultDocument": "index.html"
  3. }

This also means it is no longer necessary to specify the defaultDocument field with an empty value to prevent the redirect and be able to serve requests at the / (root) path of the mount point:

Old:

  1. {
  2.   "defaultDocument": ""
  3. }

New:

  1. {
  2.   // no defaultDocument
  3. }

Assets

The assets field is no longer supported in ArangoDB 3.0 outside of legacy compatibility mode.

If you previously used the field to serve individual files as-is you can simply use the files field instead:

Old:

  1. {
  2.   "assets": {
  3.     "client.js": {
  4.       "files": ["assets/client.js"],
  5.       "contentType": "application/javascript"
  6.     }
  7.   }
  8. }

New:

  1. {
  2.   "files": {
  3.     "client.js": {
  4.       "path": "assets/client.js",
  5.       "type": "application/javascript"
  6.     }
  7.   }
  8. }

If you relied on being able to specify multiple files that should be concatenated, you will have to use build tools outside of ArangoDB to prepare these files accordingly.

Root element

The rootElement field is no longer supported and has been removed entirely.

If your controllers relied on this field being available you need to adjust your schemas and routes to be able to handle the full JSON structure of incoming documents.

System services

The isSystem field is no longer supported. The presence or absence of the field had no effect in most recent versions of ArangoDB 2.x and has now been removed entirely.