Incompatible changes in ArangoDB 2.4

    The bundled V8 version has been upgraded from 3.16.14 to 3.29.59.

    The new version provides better error checking, which can lead to subtle changes in the execution of JavaScript code.

    The following code, though nonsense, runs without error in 2.3 and 2.4 when strict mode is not enabled:

    When enabling strict mode, the function will throw an error in 2.4 but not in 2.3:

    1. "use strict";
    2. a = true;
    3. = 1;
    4. TypeError: Cannot assign to read only property 'foo' of true

    Though this is a change in behavior it can be considered an improvement. The new version actually uncovers an error that went undetected in the old version.

    Error messages have also changed slightly in the new version. Applications thatrely on the exact error messages of the JavaScript engine may need to be adjusted so theylook for the updated error messages.

    The default endpoint for arangod is now

    This change will modify the IP address ArangoDB listens on to by default.This will make new ArangoDB installations unaccessible from clients other thanlocalhost unless the configuration is changed. This is a security feature.

    To make ArangoDB accessible from any client, change the server’s configuration (—server.endpoint) to either tcp:// or the server’s publiclyvisible IP address.

    System collections are now included in the replication and all replication API return values by default.

    This will lead to user accounts and credentials data being replicated from master to slave servers. This may overwrite slave-specific database users.

    If replication of system collections is undesired, they can be excluded from replicationby setting the includeSystem attribute to false in the following commands:

    • initial synchronization: replication.sync({ includeSystem: false })
    • continuous replication:{ includeSystem: false })

    This will exclude all system collections (including _aqlfunctions, _graphs etc.)from the initial synchronization and the continuous replication.

    If this is also undesired, it is also possible to specify a list of collections toexclude from the initial synchronization and the continuous replication using therestrictCollections attribute, e.g.:

    The above example will in general include system collections, but will exclude thespecified three collections from continuous replication.

    The HTTP REST API methods for fetching the replication inventory and for dumping collections also support the includeSystem control flag via a URL parameter ofthe same name.

    Several options for the configure command have been removed in 2.4. The options

    • —enable-all-in-one-v8
    • —enable-all-in-one-icu
    • —enable-all-in-one-libev
    • —with-libev=DIR
    • —with-libev-lib=DIR
    • —with-v8=DIR
    • —with-v8-lib=DIR

    are not available anymore because the build process will always use the bundledversions of the libraries.

    When building ArangoDB from source in a directory that already contained a pre-2.4 version, it will be necessary to run a make superclean command once and a fullrebuild afterwards:

    1. make superclean
    2. make setup
    3. ./configure <options go here>
    4. make

    As a consequence of global renaming in the codebase, the option mergeArrays hasbeen renamed to mergeObjects. This option controls whether JSON objects will be merged on an update operation or overwritten. The default has been, and still is, to merge. Not specifying the parameter will lead to a merge, as it has been thebehavior in ArangoDB ever since.

    This affects the HTTP REST API method PATCH /_api/document/collection/key. Itsoptional URL parameter mergeArrays for the option has been renamed to mergeObjects.

    The AQL UPDATE statement is also affected, as its option mergeArrays has alsobeen renamed to mergeObjects. The 2.3 query

    1. UPDATE doc IN collection WITH { ... } IN collection OPTIONS { mergeObjects: false }

    For FoxxController objects, the method collection() is deprecated and will beremoved in future version of ArangoDB. Using this method will issue a warning. Please use applicationContext.collection() instead.

    For FoxxRepository objects, the property modelPrototype is now deprecated.Using it will issue a warning. Please use FoxxRepository.model instead.

    In FoxxController / RequestContext, calling method bodyParam() with three arguments is deprecated. Please use .bodyParam(paramName, options) instead.

    In / RequestContext calling method queryParam({type: string}) is deprecated. Please use requestContext.queryParam({type: joi}) instead.

    In FoxxController / RequestContext calling method pathParam({type: string}) is deprecated. Please use requestContext.pathParam({type: joi}) instead.

    For FoxxModel, calling Model.extend({}, {attributes: {}}) is deprecated. Please use Model.extend({schema: {}}) instead.

    In module org/arangodb/general-graph, the functions _undirectedRelation() and _directedRelation() are deprecated and will be removed in a future versionof ArangoDB. Both functions have been unified to _relation().

    The modules org/arangodb/graph and org/arangodb/graph-blueprint are deprecated. Please use module org/arangodb/general-graph instead.

    The HTTP REST API _api/graph and all its methods are deprecated. Please use the general graph API _api/gharial instead.

    The following replication-related JavaScript methods became obsolete in ArangoDB2.2 and have been removed in ArangoDB 2.4:

    • require("org/arangodb/replication").logger.start()
    • require("org/arangodb/replication").logger.stop()
    • require("org/arangodb/replication")

    The REST API methods for these functions have also been removed in ArangoDB 2.4:

    • HTTP PUT /_api/replication/logger-start
    • HTTP PUT /_api/replication/logger-stop
    • HTTP GET /_api/replication/logger-config
    • HTTP PUT