Questions for matching on edge types without indexes

[randomJoe211]

Describe the bug (required)

issue 1

In Nebula Graph 2.6.x, when running MATCH ()-[e:follow]-() RETURN e and there are no edge indexes, it reports can't solve the start vids:

(root@nebula) [basketballplayer]> MATCH ()-[e:follow]-() RETURN e
[ERROR (-1009)]: SemanticError: Can't solve the start vids from the sentence: MATCH ()-[e:follow]-() RETURN e

This is reasonable. But in the 12.15 nightly version, running the same query reports Scan edges must specify limit number.

(root@nebula) [basketballplayer]> MATCH ()-[e:follow]-() RETURN e
[ERROR (-1005)]: Scan edges must specify limit number.

OK. Now I add LIMIT:

(root@nebula) [basketballplayer]> MATCH ()-[e:follow]-() RETURN e LIMIT 10
+----------------------------------------------------+
| e                                                  |
+----------------------------------------------------+
| [:follow "player101"->"player102" @0 {degree: 90}] |
| [:follow "player103"->"player102" @0 {degree: 70}] |
| [:follow "player135"->"player102" @0 {degree: 80}] |
| [:follow "player113"->"player106" @0 {degree: 99}] |
| [:follow "player114"->"player115" @0 {degree: 90}] |
| [:follow "player138"->"player115" @0 {degree: 90}] |
+----------------------------------------------------+
Got 6 rows (time spent 2789/3468 us)

Question1: How could Nebula return such results when there is no edge index at all? Does it support scanning without indexes now?
Question2: There are way more follow edges than 10, why it returns just 6 of them?

issue 2

This is the tricky part. If I specify the edge direction based on the last query, the number of returned rows is exactly 10.

(root@nebula) [basketballplayer]> MATCH ()-[e:follow]->() RETURN e LIMIT 10
+----------------------------------------------------+
| e                                                  |
+----------------------------------------------------+
| [:follow "player102"->"player100" @0 {degree: 75}] |
| [:follow "player102"->"player101" @0 {degree: 75}] |
| [:follow "player129"->"player116" @0 {degree: 90}] |
| [:follow "player129"->"player121" @0 {degree: 90}] |
| [:follow "player129"->"player128" @0 {degree: 90}] |
| [:follow "player138"->"player115" @0 {degree: 90}] |
| [:follow "player138"->"player139" @0 {degree: 99}] |
| [:follow "player108"->"player100" @0 {degree: 80}] |
| [:follow "player108"->"player101" @0 {degree: 80}] |
| [:follow "player139"->"player138" @0 {degree: 99}] |
+----------------------------------------------------+
Got 10 rows (time spent 4939/6795 us)

Question 3: Why is an arrow causing such a difference in the number of returned rows? If it is designed to be like this, I think it is strange behavior.

issue 3

If I set a vertex variable v in the query in issue 2 or issue 1, an error is reported. But the syntax should be right.

(root@nebula) [basketballplayer]> MATCH (v)-[e:follow]->() RETURN e LIMIT 10
[ERROR (-1005)]: Scan vertices must specify limit number.

Fri, 17 Dec 2021 07:58:40 UTC

(root@nebula) [basketballplayer]> MATCH (v)-[e:follow]-() RETURN e LIMIT 10
[ERROR (-1005)]: Scan vertices must specify limit number.

Question 4: Adding v should not have caused such an issue, right?
Question 5: The error message is wrong because I have LIMIT 10. I think this is the same issue with #3492. Right?

Your Environments (required)

• OS: Ubuntu 20.04
• Commit id: nebula-graphd version 2021.12.15-nightly, Git: 99f1f7a, Build Time: Dec 16 2021 03:10:58

[Shylock-Hg]

See issue 1, 2 in #3505
For issue 3, now we transform plan by checking whether the node is anonymous. If user will reference properties of vertex, can't do ScanEdges directly.