[RFC] The redefined node symbols in match pattern

[Shylock-Hg]

Summary

It implement the open cypher syntax like:

MATCH (v:player)-[:like]->(v) RETURN *;
MATCH (v:player)-[:like]->()-[:like]->(v) RETURN *;

The main principle is that there are redefined node symbols in pattern, it's v in above examples.

ps. The redefined relationship symbol is disabled in open cypher.

Motivation

It's open cypher implementation requirements.

Usage explanation

Used as said before. The user could query graph by the pattern that with redefined node symbols.

Design explanation

The mechanism aims to that the expand from known nodes to known nodes with edges, it's different to the pattern MATCH (v:player)-[:like]->() which expand from known nodes to any nodes with edges. For the second pattern now we have a method named Expand to construct the query plan, so here, I plan to introduce the new method ExpandInto to meet the new expand pattern.

For ExpandInto method, it's based on the GetNeighbor RPC with the modifications that:

1. adding one column named _dst in request dataset, as named, it's the dest vertex.
2. When the GetNeighbor scan data, it should filter edges by that does the destination vertex id same with the value of column _dst.

This won't change the return structure, so we could reuse the code to process the result of GetNeighbor.
So when do ExpandInto, the request dataset of GetNeighbor is |_vid|_dst|.

So the largest thing that we need is to resolve the symbol value when expand(e.g. v in above case). For this, given a map from symbol name to symbol value expression and it's registered when generate expand plan. And when we generate expand plan, we need to check whether destination node symbol name exists in this map. If yes, we need to generate plan by ExpandInto instead of Expand.

ps. We need named the anonymous node.

Rationale and alternatives

We could project symbols when expand, but it's seems more expensive and complex.

Drawbacks

1. Introduce new mechanism when planning.

Prior art

In neo4j, according the explained plan, it resolve the symbol when expand.

Unresolved questions

1. Now we encode the edge key as type(1) + partId(3) + srcId(*) + edgeType(4) + edgeRank(8) + dstId(*) + placeHolder(1), so we can't do prefix seek with dstId when scan edges in storage.Must filter after scan manually.

Future possibilities

It's also the basic of multiple match clauses sentence which used redefined symbol too. In that case, the resolved symbol values should be shared in different match clause when generating plan.
And the resolved symbol values could be the independent entry of seek like others(e.g properties seek entry).

[Shylock-Hg]

Replace in #3929 by filter.

[Shylock-Hg]

We could embed filter to Expand operator to get performance improvement as this issue said in future.