NEO4J 密码查询 : Relationship Direction Bug in Where Clause

Question

示例数据:

示例查询

CREATE (a1:A {title: "a1"})
CREATE (a2:A {title: "a2"})
CREATE (a3:A {title: "a3"})

CREATE (b1:B {title: "b1"})
CREATE (b2:B {title: "b2"})

MATCH (a:A {title: "a1"}), (b:B {title: "b1"})
CREATE (a)-[r:LINKS]->(b)

MATCH (a:A {title: "a2"}), (a1:A {title: "a1"}) 
CREATE (a)-[:CONNECTED]->(a1)

MATCH (a:A), (b:B) return a,b

---

Objective: Finding some connections in the where clause

现在让我们写一些变体来找到 A 不直接连接到 B(a2 和 b3)

// Q1. Both work fine
MATCH (a:A) WHERE (a)--(:B) RETURN a
MATCH (a:A) WHERE (:B)--(a) RETURN a

// Q2. Works
MATCH (a:A)-[r]-(b:B) WHERE (a)-[r]-(b) RETURN a

// Q3. Fails
MATCH (a:A)-[r]-(b:B) WHERE (b)-[r]-(a) RETURN a

知道为什么即使方向指定为双向，Q2、Q3 的行为方式也不同吗？ 这是 NEO4J 的错误吗？

All credits to stdob at this answer for narrowing down the anomaly that was happening in my other query.

---

更新:同样发布到 NEO4J GitHub issues

更新:NEO4J 已经接受了这个错误，将在 3.1 中修复它

Answer 1

虽然这可能不是一个完整的答案，但信息太多，无法发表评论。不过，这应该有望提供一些有用的见解。

我会认为这是一个错误。以下是应该从样本数据中得出相同结果的一些变体。他们都应该通过给定的数据(通过返回任何东西)

MATCH (a:A)-[r]-(b:B) WHERE (b)-[r]-(a) RETURN * -> 失败

删除r
MATCH (a:A)--(b:B) WHERE (b)--(a) RETURN * -> 通过
MATCH (a:A)-[r]-(b:B) WHERE (b)--(a) RETURN * -> 通过

添加方向
MATCH (a:A)-[r]-(b:B) WHERE (b)<-[r]-(a) RETURN * -> 通过

倒序
MATCH (a:A)-[r]-(b:B) WHERE (a)-[r]-(b) RETURN * -> 通过

并且，从失败测试的配置文件

+---------------------+----------------+------+---------+-----------+--------------+
| Operator            | Estimated Rows | Rows | DB Hits | Variables | Other        |
+---------------------+----------------+------+---------+-----------+--------------+
| +ProduceResults     |              1 |    0 |       0 | a         | a            |
| |                   +----------------+------+---------+-----------+--------------+
| +SemiApply          |              1 |    0 |       0 | a, b, r   |              |
| |\                  +----------------+------+---------+-----------+--------------+
| | +ProjectEndpoints |              1 |    0 |       0 | a, b, r   | r, b, a      |
| | |                 +----------------+------+---------+-----------+--------------+
| | +Argument         |              2 |    1 |       0 | a, b, r   |              |
| |                   +----------------+------+---------+-----------+--------------+
| +Filter             |              2 |    1 |       1 | a, b, r   | a:A          |
| |                   +----------------+------+---------+-----------+--------------+
| +Expand(All)        |              2 |    1 |       3 | a, r -- b | (b)-[r:]-(a) |
| |                   +----------------+------+---------+-----------+--------------+
| +NodeByLabelScan    |              2 |    2 |       3 | b         | :B           |
+---------------------+----------------+------+---------+-----------+--------------+

和等效的通过测试(倒序)

+---------------------+----------------+------+---------+-----------+--------------+
| Operator            | Estimated Rows | Rows | DB Hits | Variables | Other        |
+---------------------+----------------+------+---------+-----------+--------------+
| +ProduceResults     |              1 |    1 |       0 | a         | a            |
| |                   +----------------+------+---------+-----------+--------------+
| +SemiApply          |              1 |    1 |       0 | a, b, r   |              |
| |\                  +----------------+------+---------+-----------+--------------+
| | +ProjectEndpoints |              1 |    0 |       0 | a, b, r   | r, a, b      |
| | |                 +----------------+------+---------+-----------+--------------+
| | +Argument         |              2 |    1 |       0 | a, b, r   |              |
| |                   +----------------+------+---------+-----------+--------------+
| +Filter             |              2 |    1 |       1 | a, b, r   | a:A          |
| |                   +----------------+------+---------+-----------+--------------+
| +Expand(All)        |              2 |    1 |       3 | a, r -- b | (b)-[r:]-(a) |
| |                   +----------------+------+---------+-----------+--------------+
| +NodeByLabelScan    |              2 |    2 |       3 | b         | :B           |
+---------------------+----------------+------+---------+-----------+--------------+

注意每个步骤 1 之后的行数。同样的计划不应该产生不同的结果。我可以推测这是一个与图形修剪快捷方式相关的错误(即，一旦 Neo4j 沿一个方向遍历一条边，它就不会在同一场比赛中返回同一边。这是一个反循环故障安全/performance feature) 因此，理论上，在将 where 部分与 match 部分的顺序颠倒后，Neo4j 必须遍历修剪后的边以验证关系。如果方向相同，则自动通过。如果 Neo4j 尝试反向执行相同的检查，则会失败，因为该边已被修剪。 (虽然这只是理论。失败的验证在技术上是在反向验证上)