Note: this post is about the ArangoDB 3.x series

A while ago I wrote a blog post about handling binary data in Foxx applications. That blog post provided a solution for retrieving and serving non-UTF-8 data from a Foxx application. It was written for the 2.x series of ArangoDB.

With the release of ArangoDB 3.0 that solution needs some adaption, and this blog post provides the source code for the 3.0 version of the Foxx application.

Ever wondered how much heap memory will be used by STL containers, and in what chunks they will allocate it?

Here is the answer for some frequently used containers types containing uint64_t values (an 8 byte type). For the associative containers I also used uint64_t as the key type.

Why should you care about compiling ArangoDB on your own when there are official release packages that are ready to use?

Once you have set up a debug version of ArangoDB, it is quite helpful to also enable the Address Sanitizer and its companion tools.

These sanitizers provide runtime instrumentation for executables and check for common C++ programming errors such as buffer overflows, use-after-free bugs and memory leaks. The sanitizers supported natively by recent versions of g++ and clang++.

The general runtime overhead of the sanitizers is neglectable compared to other instrumentation tools such as Valgrind, so it can well be used in the day-to-day development process.

Compiling a debug version of ArangoDB is a must for everyone that wants to modify the C++ ArangoDB source code and test their changes locally.

How to do this is different in the 2.8 and 3.0 branches of ArangoDB, but luckily it’s really easy to achieve in both branches.

While doing some optimization work for the upcoming ArangoDB 3.0 release, we had to figure out what was the “ideal” way of converting a string representation of a number into a C++ uint64_t (64 bit unsigned integer type). This kind of operation is performed a lot during the lifetime of an ArangoDB server process, so it seemed worthwhile making it as fast as possible.

We have spent a lot of time working on ArangoDB 3.0. That version will not only provide major functionality and performance improvements, but will also come with an improved, CMake-based build system.

This post explains how to use CMake to build ArangoDB 3.0 on a recent Ubuntu Linux. For the impatient there’s a command summary at the end of this post.

With g++ 6 becoming more and more adopted, it’s about time to point out an issue that hit some of us ArangoDB developers and a few of our users that compile ArangoDB from source with g++ 6.

The problem is that when compiling ArangoDB with g++6 with default options, arangod starts and almost immediately segfaults.

Suppose there is an AQL query that’s executing in the server for a long time already and you want to get rid of it. What can be done to abort that query?

If a connection to the server can still be established, the easiest is to use the ArangoShell to fetch the list of currently executing AQL queries and send a kill command to the server for the correct query.

Explaining AQL queries becomes even easier in ArangoDB 2.8.

While previous versions required writing a hard-to-memoize command like

1

require("org/arangodb/aql/explainer").explain(query);

to explain an AQL query from the ArangoShell, 2.8 reduces this task to a mere

1

db._explain(query);

Apart from that, explain in 2.8 is smarter when confronted with very lengthy query strings, and with queries that contain huge hard-coded string, array, or object values.