wey
10/02/2022, 1:06 PMSandeep
10/02/2022, 8:22 PMSandeep
10/02/2022, 8:27 PMSandeep
10/06/2022, 10:32 AMSandeep
10/10/2022, 8:33 AMSandeep
10/11/2022, 11:41 PMSandeep
10/17/2022, 10:02 AMGoran Cvijanovic
10/17/2022, 11:13 AMSandeep
10/17/2022, 3:45 PMSandeep
11/14/2022, 12:26 PMGoran Cvijanovic
11/14/2022, 1:40 PMGoran Cvijanovic
11/17/2022, 9:07 AMWhen inserting an edge that already exists, INSERT VERTEX *overrides* the edge.
Goran Cvijanovic
11/29/2022, 4:08 PM[ERROR (-1005)]: Storage Error: Not the leader of 103. Please retry later.
second request returns valid response.
Also some request don’t return any results for keys that were inserted earlier.
I’ve upgraded my cluster to 3.3.0 version from 3.2.1 one node at a time.
fyi:
one parameter for rocksdb I’ve changed
--rocksdb_compression_per_level=no:no:lz4:lz4:lz4hc:lz4hc:lz4hc
from default setting that was empty string
can that change have impact to not be able to query some of the data ?
I’ve actually changed another one, using query optimizer, previously it was disabled !
--enable_optimizer=true
Goran Cvijanovic
11/29/2022, 9:00 PMGoran Cvijanovic
11/30/2022, 8:12 AME20221129 23:24:55.530879 332829 StorageAccessExecutor.h:39] IndexScanExecutor failed, error E_RPC_FAILURE, part 90
E20221129 23:24:55.530885 332829 StorageAccessExecutor.h:39] IndexScanExecutor failed, error E_RPC_FAILURE, part 92
E20221129 23:24:55.530894 332829 StorageAccessExecutor.h:39] IndexScanExecutor failed, error E_RPC_FAILURE, part 95
E20221129 23:24:55.530901 332829 StorageAccessExecutor.h:39] IndexScanExecutor failed, error E_RPC_FAILURE, part 96
E20221129 23:24:55.530913 332829 StorageAccessExecutor.h:136] Storage Error: part: 124, error: E_RPC_FAILURE(-3).
E20221129 23:24:55.530952 332825 QueryInstance.cpp:137] Storage Error: part: 124, error: E_RPC_FAILURE(-3).
Sandeep
12/01/2022, 2:11 PMSandeep
02/01/2023, 3:20 PMSandeep
02/16/2023, 10:40 AMKasper
02/20/2023, 11:30 AMGoran Cvijanovic
02/20/2023, 1:00 PMOpenCypher has no such concept as rank.
Goran Cvijanovic
02/20/2023, 1:01 PMSandeep
03/06/2023, 7:54 AMGoran Cvijanovic
03/06/2023, 8:25 AMSandeep
03/16/2023, 8:48 AMwey
03/16/2023, 2:13 PMSandeep
04/07/2023, 8:02 AMZijin Jiang
06/25/2023, 9:39 AMManuel Costa
07/06/2023, 2:50 PMManuel Costa
07/12/2023, 5:31 PMMarija Zelić
08/24/2023, 10:33 AMEMPTY
and NULL
, when displaying an edge with one missing vertex.
it seems that if a source vertex is missing, Nebula displays EMPTY (and you can filter with: IS NOT EMPTY). However, if a destination vertex is missing, Nebula displays NULL (and you can filter with: IS NOT NULL). Is there a reason for such difference, and is it safe to rely on such EMPTY/NULL filtering in queries (or is this likely to change in new Nebula versions)? Here is a short example:
CREATE TAG player(name string)
CREATE EDGE follow()
INSERT VERTEX player(name) VALUES "001":("John")
INSERT VERTEX player(name) VALUES "002":("Michael")
INSERT EDGE follow () VALUES '001' -> '002':()
(manager@nebula) [rlgraph]> GO FROM '001' OVER follow YIELD $^.player.name as player1, $$.player.name AS player2
| player1 | player2 |
| "John" | "Michael" |
DELETE VERTEX '001'
(manager@nebula) [rlgraph]> GO FROM '001' OVER follow YIELD $^.player.name as player1, $$.player.name AS player2
| player1 | player2 |
| | "Michael" |
INSERT VERTEX player(name) VALUES "001":("John")
DELETE VERTEX '002'
(manager@nebula) [rlgraph]> GO FROM '001' OVER follow YIELD $^.player.name as player1, $$.player.name AS player2
| player1 | player2 |
| "John" | __NULL__ |