ArangoDB v3.12 is under development and not released yet. This documentation is not final and potentially incomplete.
Incompatible changes in ArangoDB 3.6
Check the following list of potential breaking changes before upgrading to this ArangoDB version and adjust any client applications if necessary
ArangoDB 3.6 enforces valid date ranges for working with date/time in AQL. The valid date ranges for any AQL date/time function are:
- for string date/time values:
"0000-01-01T00:00:00.000Z"(including) up to
- for numeric date/time values: -62167219200000 (including) up to
253402300799999 (including). These values are the numeric equivalents of
Any date/time values outside the given range that are passed into an AQL date
function will make the function return
null and trigger a warning in the
query, which can optionally be escalated to an error and stop the query.
Any date/time operations that produce date/time outside the valid ranges stated
above will make the function return
null and trigger a warning too. Example:
DATE_SUBTRACT("2018-08-22T10:49:00+02:00", 100000, "years") // null
The following startup options have been removed in ArangoDB 3.6:
--vst.maxsize: this option was used in previous versions to control the maximum size (in bytes) of VelocyPack chunks when using the VelocyStream (VST) protocol. This is now handled automatically by the server and does not need any configuration.
The MMFiles storage engine is deprecated starting with version 3.6.0 and it will be removed in a future release.
We recommend to switch to RocksDB even before the removal of MMFiles. RocksDB is the default storage engine since v3.4.0.
Introduced in: v3.6.5
Previous versions of ArangoDB excluded all requests made to the web interface at
/_admin/aardvark from the requests statistics if the request was made for the
_system database. Requests for all other endpoints or requests to the same
endpoint for any non-system database were already counted.
ArangoDB now treats all incoming requests to the web interface in the same
way as requests to other endpoints, so the request counters may show higher
values than before in case the web interface was used a lot on the