« Changelog History


ArangoDB v3.4.2 Release Notes

Release Date: 2019-01-24 // over 5 years ago

    • ➕ added configurable masking of dumped data via arangodump tool to obfuscate exported sensible data

    • ⬆️ upgraded to OpenSSL 1.1.0j

    • 🛠 fixed an issue with AQL query IN index lookup conditions being converted into empty arrays when they were shared between multiple nodes of a lookup condition that used an IN array lookup in an OR that was multiplied due to DNF transformations

    This issue affected queries such as the following

      FILTER (... && ...) || doc.indexAttribute IN non-empty-array

    • ⬆️ upgraded arangodb starter version to 0.14.0

    • ⬆️ upgraded arangosync version to 0.6.2

    • 🛠 fixed an issue where a crashed coordinator can lead to some Foxx queue jobs erroneously either left hanging or being restarted

    • 🛠 fix issue #7903: Regression on ISO8601 string compatibility in AQL

    millisecond parts of AQL date values were limited to up to 3 digits. Now the length of the millisecond part is unrestricted, but the millisecond precision is still limited to up to 3 digits.

    • 🛠 fix issue #7900: Bind values of null are not replaced by empty string anymore, when toggling between json and table view in the web-ui.

    • 👉 Use base64url to encode and decode JWT parts.

    • ➕ added AQL function CHECK_DOCUMENT for document validity checks

    • ⏪ when detecting parse errors in the JSON input sent to the restore API, now abort with a proper error containing the problem description instead of aborting but hiding there was a problem.

    • 📜 do not respond with an internal error in case of JSON parse errors detected in incoming HTTP requests

    • ➕ added arangorestore option --cleanup-duplicate-attributes to clean up input documents with redundant attribute names

    Importing such documents without the option set will make arangorestore fail with an error, and setting the option will make the restore process clean up the input by using just the first specified value for each redundant attribute.

    • ⏪ the arangorestore options --default-number-of-shards and --default-replication-factor are now deprecated in favor of the much more powerful options --number-of-shards and --replication-factor

    The new options --number-of-shards and --replication-factor allow specifying default values for the number of shards and the replication factor, resp. for all restored collections. If specified, these default values will be used regardless of whether the number of shards or the replication factor values are already present in the metadata of the dumped collections.

    It is also possible to override the values on a per-collection level by specifying the options multiple times, e.g.

      --number-of-shards 2 --number-of-shards mycollection=3 --number-of-shards test=4

    The above will create all collections with 2 shards, except the collection "mycollection" (3 shards) and "test" (4 shards).

    By omitting the default value, it is also possible to use the number of shards/replication factor values from the dump for all collections but the explicitly specified ones, e.g.

      --number-of-shards mycollection=3 --number-of-shards test=4

    This will use the number of shards as specified in the dump, except for the collections "mycollection" and "test".

    The --replication-factor option works similarly.

    • validate uniqueness of attribute names in AQL in cases in which it was not done before. When constructing AQL objects via object literals, there was no validation about object attribute names being unique. For example, it was possible to create objects with duplicate attribute names as follows:

      INSERT { a: 1, a: 2 } INTO collection

    This resulted in a document having two "a" attributes, which is obviously undesired. Now, when an attribute value is used multiple times, only the first assigned value will be used for that attribute in AQL. It is not possible to specify the same attribute multiple times and overwrite the attribute's value with by that. That means in the above example, the value of "a" will be 1, and not 2. This changes the behavior for overriding attribute values in AQL compared to previous versions of ArangoDB, as previous versions in some cases allowed duplicate attribute names in objects/documents (which is undesired) and in other cases used the last value assigned to an attribute instead of the first value. In order to explicitly override a value in an existing object, use the AQL MERGE function.

    To avoid all these issues, users are encouraged to use unambiguous attribute names in objects/documents in AQL. Outside of AQL, specifying the same attribute multiple times may even result in a parse error, e.g. when sending such data to ArangoDB's HTTP REST API.

    • 🛠 fixed issue #7834: AQL Query crashes instance

    • ➕ Added --server.jwt-secret-keyfile option.

    • 👌 Improve single threaded performance by scheduler optimization.

    • 🚧 Releveling logging in maintenance