Features and Improvements in ArangoDB 2.4

    The built-in version of V8 has been upgraded from 3.16.14 to 3.29.59.This activates several ES6 (also dubbed Harmony or ES.next) features inArangoDB, both in the ArangoShell and the ArangoDB server. They can beused for scripting and in server-side actions such as Foxx routes, traversalsetc.

    The following ES6 features are available in ArangoDB 2.4 by default:

    • iterators
    • the operator
    • symbols
    • predefined collections types (Map, Set etc.)
    • typed arrays

    Many other ES6 features are disabled by default, but can be made available bystarting arangod or arangosh with the appropriate options:

    • arrow functions
    • proxies
    • generators
    • String, Array, and Number enhancements
    • constants
    • enhanced object and numeric literals

    To activate all these ES6 features in arangod or arangosh, start it with the following options:

    More details on the available ES6 features can be found in .

    ArangoDB 2.4 is shipped with FoxxGenerator, a framework for buildingstandardized Hypermedia APIs easily. The generated APIs can be consumed withclient tools that understand Siren.

    Hypermedia is the simple idea that our HTTP APIs should have links between theirendpoints in the same way that our web sites have links betweenthem. FoxxGenerator is based on the idea that you can represent an API as astatechart: Every endpoint is a state and the links are the transitions betweenthem. Using your description of states and transitions, it can then create anAPI for you.

    The FoxxGenerator can create APIs based on a semantic description of entitiesand transitions. A blog series on the use cases and how to use the Foxx generatoris here:

    The AQL optimizer has been enhanced to use of indexes in queries in several additional cases. Filters containing the IN operator can now make use of indexes, and multiple OR- or AND-combined filter conditions can now also use indexes if the filter conditions refer to the same indexed attribute.

    Here are a few examples of queries that can now use indexes but couldn’t before:

    1. FOR doc IN collection
    2.   FILTER doc.indexedAttribute == 1 || doc.indexedAttribute > 99
    3.   RETURN doc
    5. FOR doc IN collection
    6.   FILTER doc.indexedAttribute IN [ 3, 42 ] || doc.indexedAttribute > 99
    7.   RETURN doc
    9. FOR doc IN collection
    10.   FILTER (doc.indexedAttribute > 2 && doc.indexedAttribute < 10) ||
    11.          (doc.indexedAttribute > 23 && doc.indexedAttribute < 42)
    12.   RETURN doc

    Additionally, the optimizer rule remove-filter-covered-by-index has beenadded. This rule removes FilterNodes and CalculationNodes from an execution plan if the filter condition is already covered by a previous IndexRangeNode. Removing the filter’s CalculationNode and the FilterNode itself will speedup query execution because the query requires less computation.

    Data-modification queries returning documents

    INSERT, REMOVE, UPDATE or REPLACE queries now can optionally return the documents inserted, removed, updated, or replaced. This is helpful for trackingthe auto-generated attributes (e.g. _key, _rev) created by an INSERT and ina lot of other situations.

    In order to return documents from a data-modification query, the statement mustimmediately be immediately followed by a LET statement that assigns either the pseudo-value NEW or OLD to a variable. This LET statement must be followed by a RETURN statement that returns the variable introduced by LET:

    1. FOR i IN 1..100
    2.   INSERT { value: i } IN test LET inserted = NEW RETURN inserted
    4. FOR u IN users
    5.   FILTER u.status == 'deleted'
    6.   REMOVE u IN users LET removed = OLD RETURN removed
    8. FOR u IN users
    9.   FILTER u.status == 'not active'
    10.   UPDATE u WITH { status: 'inactive' } IN users LET updated = NEW RETURN updated

    NEW refers to the inserted or modified document revision, and OLD refersto the document revision before update or removal. INSERT statements can only refer to the NEW pseudo-value, and REMOVE operations only to OLD. UPDATE and REPLACE can refer to either.

    In all cases the full documents will be returned with all their attributes,including the potentially auto-generated attributes such as _id, _key, or _revand the attributes not specified in the update expression of a partial update.

    COUNT clause

    An optional COUNT clause was added to the COLLECT statement. The COUNTclause allows for more efficient counting of values.

    In previous versions of ArangoDB one had to write the following to countdocuments:

    With the COUNT clause, the query can be modified to

    1. FOR doc IN collection
    2.   FILTER ...some condition...
    3.   COLLECT WITH COUNT INTO length
    4.   RETURN length

    The latter query will be much more efficient because it will not produce anyintermediate results with need to be shipped from a subquery into the LENGTHfunction.

    The COUNT clause can also be used to count the number of items in each group:

    1.   FILTER ...some condition...
    2.   COLLECT group = doc.group WITH COUNT INTO length
    3.   return { group: group, length: length }

    COLLECT modifications

    In ArangoDB 2.4, operations can be made more efficient if only a small fragment of the group values is needed later. For these cases, COLLECTprovides an optional conversion expression for the INTO clause. This expression controls the value that is inserted into the array of group values.It can be used for projections.

    The following query only copies the dateRegistered attribute of each documentinto the groups, potentially saving a lot of memory and computation time compared to copying doc completely:

    1. FOR doc IN collection
    2.   FILTER ...some condition...
    3.   COLLECT group = doc.group INTO dates
    4.   return { group: group, maxDate: MAX(dates[*].doc.dateRegistered) }

    The above query will need to copy the full doc attribute into the lengthsvariable, whereas the new variant will only copy the dateRegisteredattribute of each doc.

    Subquery syntax

    In previous versions of ArangoDB, subqueries required extra parenthesesaround them, and this caused confusion when subqueries were used as functionparameters. For example, the following query did not work:

    1. LET values = LENGTH(
    2.   FOR doc IN collection RETURN doc
    3. )

    but had to be written as follows:

    This was unintuitive and is fixed in version 2.4 so that both variants of the query are accepted and produce the same result.

    Web interface

    The Applications tab for Foxx applications in the web interface has got a complete redesign.

    It will now only show applications that are currently running in ArangoDB. For a selected application, a new detailed view has been created. This view provides a better overview of the app, e.g.:

    • author
    • license
    • version
    • contributors
    • download links
    • API documentation

    Installing a new Foxx application on the server is made easy using the newAdd application button. The Add application dialog provides all the features already available in the foxx-manager console application plus some more:

    • install a Foxx application from Github
    • install a Foxx application from a zip file
    • install a Foxx application from ArangoDB’s application store
    • create a new Foxx application from scratch: this feature uses a generator tocreate a Foxx application with pre-defined CRUD methods for a given list of collections. The generated Foxx app can either be downloaded as a zip file or be installed on the server. Starting with a new Foxx app has never been easier.

    The default endpoint for the ArangoDB server has been changed from 0.0.0.0 to127.0.0.1. This will make new ArangoDB installations unaccessible from clients other than localhost unless the configuration is changed. This is a security precautionmeasure that has been requested as a feature a lot of times.

    If you are the development option —enable-relative, the endpoint will stillbe 0.0.0.0.

    System collections in replication

    By default, system collections are now included in replication and all replication API return values. This will lead to user accounts and credentials data being replicated from master to slave servers. This may overwrite slave-specific database users.

    If this is undesired, the _users collection can be excluded from replicationeasily by setting the includeSystem attribute to false in the following commands:

    • replication.sync({ includeSystem: false });
    • replication.applier.properties({ includeSystem: false });

    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.:

    1. require("org/arangodb/replication").applier.properties({ 
    2.   includeSystem: true,
    3.   restrictType: "exclude",