This version is deprecated. Download the new version of ArangoDB

We are proud to announce the beta release of ArangoDB 2.2. It is a major step forward, improving the usability of AQL and graphs a lot. As always, a lot of small improvements are incorporated into your favourite NoSQL database – we will list them in a separated blog entry. However, the three major improvements are

  • a new and improved graph module
  • modifying AQL
  • a true write-a-head log

While the latter is a big step on the way to automatic failover and synchronous replication, it is mostly hidden from the user. A more detailed description will follow in the next days. The new graph module is directly visible and intended to be used by you. Graphs are much more flexible now. You can easily use more than one vertex collection to group your vertex documents into “classes”. For example, for a bipartite graph, use two vertex collections – one for each part. You can even group your edges. Use one collection for each type (“friendship” and “alliance”). Or what about Graphs-on-Graphs! Why on earth would you like to do that? Well, consider a street map, where the junctions are vertices, the edges are street segments between junctions. Now put another graph on top, to model streets as segments – again more information is coming its way. The graph viewer works with these extended graphs and even allows you to explore sharded graphs with billions of nodes. With AQL you could always express joins, aggregate, traversals – all in a convenient query language, but only for reading. You can now also modify documents or create new ones using AQL. To copy a collection you can use

or create a projection

or update, or remove, or or or. The possibilities are endless. The beta version is a preview. Please do not use it in production. We plan to release the final 2.2.0 in a few days. Currently there are the following known issues which will be fixed in the next release:

  • documentation is not yet complete
  • the db.collection.rename() command is not honored when replaying a write-ahead logfile. If such rename operation is contained in a write-ahead logfile, it will not be re-executed on startup, and the collection might be present with the old name instead.
  • the db.collection.properties(…) command is not honored when replaying a write-ahead logfile. If such property change operation is contained in a write-ahead logfile, it will not be re-executed on startup, the collection might still have its original properties.
  • empty write-ahead logfiles (with size of 0 bytes) will prevent the server from starting. The server will print the error message “datafile ‘…’ is corrupt, size is only 0” and terminate. This can be fixed manually by removing the logfiles with a size of 0 bytes from the /journals directory.
  • some dynamic memory allocated during recovery is not freed
  • Foxx application directories of databases that are dropped might be re-dropped when the server is started. This might cause issues if a Foxx application is contained in a database that is dropped and later re-created with the same name.
  • AQL update queries are partly non-functional

Please report any additional issues you find. Thanks for your help Frank