|
1 | 1 | Known Issues |
2 | 2 | ============ |
3 | 3 |
|
4 | | -The following known issues are present in this version of ArangoDB and will be fixed |
5 | | -in follow-up releases: |
6 | | - |
7 | | -Modifing documents in cluster using AQL and an incorrect custom shard key |
8 | | -------------------------------------------------------------------------- |
9 | | - |
10 | | -* In a very uncommon edge case there is an issue with an optimization rule in the cluster. |
11 | | - |
12 | | - If you are running a cluster and use a custom shard key on a collection (default is `_key`) |
13 | | - **and** you provide a wrong shard key in a modifying query (`UPDATE`, `REPLACE`, `DELETE`) |
14 | | - **and** the wrong shard key is on a different shard than the correct one, you'll get a |
15 | | - `DOCUMENT NOT FOUND` error, instead of a modification. |
16 | | - |
17 | | - The modification always happens if the rule is switched off. |
18 | | - |
19 | | - Example query: |
20 | | - |
21 | | - UPDATE { _key: "123", shardKey: "wrongKey"} WITH { foo: "bar" } IN mycollection |
22 | | - |
23 | | - If your setup could run into this issue you may want to |
24 | | - [deactivate the optimizing rule](../../AQL/ExecutionAndPerformance/Optimizer.html#turning-specific-optimizer-rules-off) |
25 | | - `restrict-to-single-shard`. |
26 | | - |
27 | | -More details can be found in [issue 6399](https://github.com/arangodb/arangodb/issues/6399). |
| 4 | +This page lists important issues of the ArangoDB suite of products all users |
| 5 | +should take note of. It is not a list of all open issues. |
28 | 6 |
|
| 7 | +ArangoDB Customers can access the |
| 8 | +[_Technical & Security Alerts_](https://arangodb.atlassian.net/wiki/spaces/DEVSUP/pages/223903745) |
| 9 | +page after login in the Support Portal. |
29 | 10 |
|
30 | 11 | ArangoSearch |
31 | 12 | ------------ |
32 | 13 |
|
33 | | -* ArangoSearch index format in 3.4RC3 is incompatible to earlier issued release candidates |
34 | | -* ArangoSearch index format in 3.4RC4 is incompatible to earlier issued release candidates |
35 | | -* ArangoSearch ignores `_id` attribute even if `includeAllFields` is set to `true` (internal #445) |
36 | | -* Using score functions (BM25/TFIDF) in ArangoDB expression is not supported (internal #316) |
37 | | -* Using a loop variable in expressions within a corresponding SEARCH condition is not supported (internal #318) |
38 | | -* Score values evaluated by corresponding score functions (BM25/TFIDF) may differ in single-server and cluster with a collection having more than 1 shard (internal #508) |
39 | | -* ArangoSearch index consolidation doesn't work during creation of a link on existing collection which may lead to massive file descriptors consumption (intenal #509) |
40 | | -* Long-running DML transactions on collections (linked with ArangoSearch view) block "ArangoDB flush thread" making impossible to refresh data "visible" by a view (internal #510) |
| 14 | +| # | Issue | |
| 15 | +|---|------------| |
| 16 | +| 9 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** Cluster <br> **Description:** Score values evaluated by corresponding score functions (BM25/TFIDF) may differ in single-server and cluster with a collection having more than 1 shard <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#508](https://github.com/arangodb/backlog/issues/508) (internal) | |
| 17 | +| 8 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** Cluster <br> **Description:** ArangoSearch index consolidation does not work during creation of a link on existing collection which may lead to massive file descriptors consumption <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#509](https://github.com/arangodb/backlog/issues/509) (internal) | |
| 18 | +| 7 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** Cluster <br> **Description:** Long-running DML transactions on collections (linked with ArangoSearch view) block "ArangoDB flush thread" making impossible to refresh data "visible" by a view <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#510](https://github.com/arangodb/backlog/issues/510) (internal) | |
| 19 | +| 6 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** ArangoSearch index format included starting from 3.4.0-RC.4 is incompatible to earlier released 3.4.0 release candidates. Dump and restore is needed when upgrading from 3.4.0-RC.4 to a newer 3.4.0.x release <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** N/A | |
| 20 | +| 5 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** RocksDB recovery fails sometimes after renaming a view <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#469](https://github.com/arangodb/backlog/issues/469) (internal) | |
| 21 | +| 4 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** ArangoSearch ignores `_id` attribute even if `includeAllFields` is set to `true` <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#445](https://github.com/arangodb/backlog/issues/445) (internal) | |
| 22 | +| 3 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** Using a loop variable in expressions within a corresponding SEARCH condition is not supported <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#318](https://github.com/arangodb/backlog/issues/318) (internal) | |
| 23 | +| 2 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** Using score functions (BM25/TFIDF) in ArangoDB expression is not supported <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/backlog#316](https://github.com/arangodb/backlog/issues/316) (internal) | |
| 24 | +| 1 | **Date Added:** 2018-12-03 <br> **Component:** ArangoSearch <br> **Deployment Mode:** All <br> **Description:** ArangoSearch index format included starting from 3.4.0-RC.3 is incompatible to earlier released 3.4.0 release candidates. Dump and restore is needed when upgrading from 3.4.0-RC.2 to a newer 3.4.0.x release <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** N/A | |
| 25 | + |
| 26 | + |
| 27 | +AQL |
| 28 | +--- |
| 29 | + |
| 30 | +| # | Issue | |
| 31 | +|---|------------| |
| 32 | +| 1 | **Date Added:** 2018-09-05 <br> **Component:** AQL <br> **Deployment Mode:** Cluster <br> **Description:** In a very uncommon edge case there is an issue with an optimization rule in the cluster. If you are running a cluster and use a custom shard key on a collection (default is `_key`) **and** you provide a wrong shard key in a modifying query (`UPDATE`, `REPLACE`, `DELETE`) **and** the wrong shard key is on a different shard than the correct one, a `DOCUMENT NOT FOUND` error is returned instead of a modification (example query: `UPDATE { _key: "123", shardKey: "wrongKey"} WITH { foo: "bar" } IN mycollection`). Note that the modification always happens if the rule is switched off, so the suggested workaround is to [deactivate the optimizing rule](../../AQL/ExecutionAndPerformance/Optimizer.html#turning-specific-optimizer-rules-off) `restrict-to-single-shard`. <br> **Affect Versions:** 3.4.0-RC.5 <br> **Fixed in Versions:** - <br> **Reference:** [arangodb/arangodb#6399](https://github.com/arangodb/arangodb/issues/6399) | |
0 commit comments