Closed azakkerman closed 2 years ago
Hi @azakkerman
I'm not sure I got the point here (I didn't run the test yet, to be honest), you are executing this query
String outerQueryOriginal =
"TRAVERSE OUT('Link') FROM ("
+ innerQuery
+ ") WHILE $depth <= 1 STRATEGY BREADTH_FIRST";
and you say that you expect three nodes in the result, but this is not the expected result: the third node has $depth = 2
, so it will be discarded.
Am I missing something?
Thanks
Luigi
Hi, Luigi,
And thank you for looking into it.
Anatoly.
Hi @azakkerman
Ok, I got the point and I think I know where the problem is. Historically, the TRAVERSE statement does not re-traverse already traversed records, so the second time it reaches the node 2 it discards it, so it does not proceed to traverse node 3.
A possible solution is to replace the TRAVERSE with a MATCH with while
condition (that does not discard duplicates), but you have to do some refactoring of the queries
Thanks
Luigi
Hi, @luigidellaquila,
These semantics don’t seem to be stable. It would imply that depending on the order in which the outer traversal runs on the FROM nodes, it will produce different results. That seems to violate basic principles of SQL. If outer traversal has a WHILE clause, it should not be pruning potential nodes the first time a node is visited and doesn't match the WHILE clause, since there are possible other paths to that node that do match the WHILE clause.
The workaround also seems to illustrate that if the nodes returned from the inner traversal are simply re-selected and fed into the outer traversal, then the outer traversal works as expected, not pruning the search prematurely? Thank you, Anatoly.
OrientDB Version: 3.0.11
Java Version: 1.8
OS: Linux
Expected behavior
We expected outer traversal based on the subquery to return one additional node (this is indeed the behavior we observed on 2.1.7)
Actual behavior
Outer traversal does not find the extra node
Workaround
'Shield' the inner traversal with nested SELECT by id.
Minimal code to reproduce the bug