vesoft-inc / nebula

A distributed, fast open-source graph database featuring horizontal scalability and high availability
https://nebula-graph.io
Apache License 2.0
10.68k stars 1.2k forks source link

Support to specify a tag property for vertex in MATCH #2659

Open yixinglu opened 3 years ago

yixinglu commented 3 years ago

Schema

CREATE TAG player(name string);
CREATE TAG bachelor(name string);
INSERT VERTEX player(name) VALUES "Tim Duncan": ("Tim Duncan");
INSERT VERTEX bachelor(name) VALUES "Tim Duncan": ("psychology");

MATCH

We can not filter the vertex v by the player.name tag condition in following MATCH query:

MATCH (v:player:bachelor)
WHERE v.name CONTAINS "Tim"
RETURN v

v.player.name will be conflict with v.map_prop.map_key in syntax.

New Syntax

MATCH (v:player:bachelor)
WHERE v:player.name CONTAINS "Tim"
RETURN v

v:player.name means player.name of vertex v clearly. And this syntax is consistent with the TCK case and the representation way of vertex.

One more thing

In addition, we can also update the nGQL start/end node syntax to follow the rule, such as:

GO FROM "Tim Duncan" OVER like YIELD WHERE $$:player.name CONTAINS "Tim" YIELD $^:player.name

Reference

jyz0309 commented 3 years ago

I want to try this issue, and can you teach me I need to read which file to get the logic? Thanks!😊

yixinglu commented 3 years ago

I want to try this issue, and can you teach me I need to read which file to get the logic? Thanks!😊

Hi @jyz0309 , sorry to reply too late.

You can start this issue from the parser file in parser.yy. Update related match clause and generate TagPropertyExpression in expression definition.

If you have any other questions, be free to let me know that.

jyz0309 commented 3 years ago

I have a little question want to ask...😭

  1. Actually I have not learned the flex/bison before, so it takes me too long to learn. So maybe I will fix this issue use more time. Can you bear it? Or maybe you can fix it first and I get another issue.
  2. I try to understand the parser.yy. In my thinking, I need to update the MatchClauseList in parser.yy, and modify the MatchSentence.cpp? I don’t know if my thinking is right, so I want to desire you for help.
  3. I want to know what the issue want to see. Is the nGQL return the v.player.name and bachelor?
    MATCH (v:player:bachelor)
    WHERE v:player.name CONTAINS "Tim"
    RETURN v
yixinglu commented 3 years ago

I think there should be enough time for you to work on it. The essence of the issue is the difference of design in schema between openCypher and Nebula Graph. Nebula Graph is a schema-based system and expects user to specify which tag/edge the property are from. However, in order to keep the compatibility with openCypher, nebula also support the v.prop-like expressions now.

as my description, v:player.name will only evaluate the expression on name property of player tag of variable v which maybe have other tags such as bachelor. In nGQL, the syntax is $$.player.name or $-.player.name if you want to fetch the player tag's name property. Maybe we can unify the syntax with above expressions such as $$:player.name and $-:player.name later.

In parser.yy, you can start at the expression, and support a new expression syntax to construct the TagPropertyExpression. You maybe need to do some debug things for the new match feature. Don't worry to raise them here.

czpmango commented 1 year ago

It is necessary to unify the design syntax and semantics, such as properties(v).name -> properties(v).player.name match (v{name:"A"}) -> match (v{player.name:"A"})

yixinglu commented 1 year ago

now it seems that we should not allow user to access the property of vertex in the only one format: v.tag.prop. it will let the query be more complex and break the compatibility with openCypher.

The v:tag.prop syntax only is an enhancement for v.prop and gives the user a way to specify which tag the prop is from. If the user don't do that, nebula also don't keep the response result always same. That's enough!

v.tag.prop-like implementation let the nebula core be complex and also be hard to do some semantic checks, because it mixes the representation between attribute access and property access. we could not do anything in semantic level when we meet the following case: map.key:tag.prop, which means map.key is also a vertex and continue to access its prop in the tag.

WDYT @MuYiYong