I just stumbled upon a comment in the ArangoDB blog asking how to create a diff of two documents with AQL.

Though there is no built-in AQL function to diff two documents, it is easily possible to build your own like in the following query.

While in search for further AQL query optimizations last week, we found that intermediate AQL query results were copied one time too often in some cases.

Precisely, the data that a query’s ReturnNode will return to the caller was copied into the ReturnNode’s own register. With ReturnNode’s never modifying their input data, this demanded for something that is called return-value optimization in compilers.

Waiting for a git pull to complete over an 8 KiB/s internet connection is boring. So I thought I’d rather use the idle time and quickly write about some performance improvements for certain AQL functions that were recently completed and that will become available with ArangoDB 2.6.

The improvements affect the following AQL functions:

ArangoDB 2.6 will feature an alternative hash implementation of the AQL COLLECT operation. The new implementation can speed up some AQL queries that can not exploit indexes on the COLLECT group criteria.

This blog post provides a preview of the feature and shows some nice performance improvements. It also explains the COLLECT-related optimizer parts and how the optimizer will decide whether to use the new or the traditional implementation.

Introduction to COLLECT

A quick recap: in AQL, the COLLECT operation can be used for grouping and optionally counting values.

The latest update to the AQL Query Builder for JavaScript addresses a major pain point: the “prefix notation” or LISP style syntax of AQL operator methods. Instead of calling the operator methods on the query builder object itself, you can now directly call them as methods on value objects.

Let’s say you want to write a query that takes all non-admin users with a power level over 9000 and returns their score rounded to the closest 100. In plain AQL this could be written like this:

FOR user IN users
FILTER user.isAdmin == false && user.powerLevel > 9000
RETURN ROUND(user.score / 100) * 100

..

Data-modification queries were enhanced in ArangoDB 2.4 to be able to also return the inserted, update or removed documents. For example, the following statement inserted a few documents and also returned them with all their attributes:

FOR i IN 1..10
  INSERT { value: i } IN test
  LET inserted = NEW
  RETURN inserted

The syntax for returning documents from data-modification queries only supported the exact above format. Using a LET clause was required, and the RETURN clause was limited to returning the variable introduced by the LET. These syntax restrictions have been lifted in the devel..

This week saw the completion of the AQL UPSERT command. This command will be very helpful in a lot of use cases, including the following:

Contained in 2.5 are some small but useful AQL language improvements plus several AQL optimizer improvements.

We are working on further AQL improvements for 2.5, but work is still ongoing. This post summarizes the improvements that are already completed and will be shipped with the initial ArangoDB 2.5 release.

On our mailing list, there is quite often the question whether attribute names in objects returned from AQL queries can be made dynamic. Jan discusses in his blog how such dynamic attribute names could be expressed and shows the current implementation that comes with ArangoDB 2.5 – adapting an ES6 proposal that might bring robust dynamic variable names to JavaScript as well.

In ArangoDB 2.5 you will be able to use dynamic variable names as follows:

Jan blogged about some recent extensions for the AQL graph traversal functionality in ArangoDB. These extensions allow invoking user-defined JavaScript code for filtering and results generation in AQL queries that contain traversals.