arangodb/Documentation/Books/Manual/ReleaseNotes/UpgradingChanges35.md

Incompatible changes in ArangoDB 3.5

It is recommended to check the following list of incompatible changes before upgrading to ArangoDB 3.5, and adjust any client programs if necessary.

The following incompatible changes have been made in ArangoDB 3.5:

Web interface

Potentially different sort order of documents

In the list of documents for a collection, the documents will now always be sorted in lexicographical order of their _key values. An exception for keys representing quasi-numerical values has been removed when doing the sorting in the web interface.

Therefore a document with a key value "10" will now be displayed before a document with a key value of "9".

Removal of index types "skiplist" and "persistent" (RocksDB engine)

For the RocksDB engine, the selection of index types "persistent" and "skiplist" has been removed from the web interface when creating new indexes.

The index types "hash", "skiplist" and "persistent" are just aliases of each other when using the RocksDB engine, so there is no need to offer all of them in parallel.

AQL

3.5 enforces the invalidation of variables in AQL queries after usage of a AQL COLLECT statements as documented. The documentation for variable invalidation claims that

The COLLECT statement will eliminate all local variables in the current scope. 
After COLLECT only the variables introduced by COLLECT itself are available.

However, the described behavior was not enforced when a COLLECT was preceded by a FOR loop that was itself preceded by a COLLECT. In the following query the final RETURN statement accesses variable key1 though the variable should have been invalidated by the COLLECT directly before it:

FOR x1 IN 1..2 
  COLLECT key1 = x1 
  FOR x2 IN 1..2 
    COLLECT key2 = x2 
    RETURN [key2, key1] 

In previous releases, this query was parsed ok, but the contents of variable key1 in the final RETURN statement were undefined.

This change is about making queries as the above fail with a parse error, as an unknown variable key1 is accessed here, avoiding the undefined behavior. This is also in line with what the documentation states about variable invalidation.