-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bug #1337 from ent #4740
Fix bug #1337 from ent #4740
Conversation
8bec593
to
0e5f0ff
Compare
May need discuss with PD |
0e5f0ff
to
d37868c
Compare
d37868c
to
4e569d7
Compare
I think you should delete the syntax in parser too. |
4e569d7
to
5737b08
Compare
I tried. With the above syntax removed in
I think it's better to report "No tag found for property". That would guide the user to add a tag to a specific property in the query. With only a syntax error, the user may be confused about what exaclty the error is. |
|
@@ -192,6 +192,12 @@ Status MatchValidator::buildNodeInfo(const MatchPath *path, | |||
auto alias = node->alias(); | |||
auto *props = node->props(); | |||
auto anonymous = false; | |||
// if there exists some property with no tag, return a semantic error | |||
if (node->labels() == nullptr && props != nullptr) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Directly props != nullptr
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems ok to remove node->labels() == nullptr
. Removed.
""" | ||
MATCH (v{name: "Tim Duncan"}) return v | ||
""" | ||
Then a ExecutionError should be raised at runtime: Scan vertices or edges need to specify a limit number, or limit number can not push down. | ||
When executing query: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not delete test cases. Modify it if the test case behavior changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Relocated this case to a new scenario match_with_wrong_syntax
in Base.feature
.
@@ -137,7 +137,7 @@ Feature: Basic match | |||
| "serve" | "Cavaliers" | | |||
When executing query: | |||
""" | |||
MATCH (v1:player{name: "LeBron James"}) -[r:serve]-> (v2 {name: "Cavaliers"}) | |||
MATCH (v1:player{name: "LeBron James"}) -[r:serve]-> (v2:team{name: "Cavaliers"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI. Since all property names must be attached to a tag name, isn't this more intuitive to design the syntax:
MATCH (v1:player{player.name: "LeBron James"}) -[r:serve]-> (v2{team.name: "Cavaliers"})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. This seems like a request for a new alternative for writing match patterns. May need to discuss with PD (and check with GQL standards).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe open an issue on this?
@@ -310,7 +310,7 @@ Feature: Variable length Pattern match (m to n) | |||
Scenario: multi-steps and filter by node properties | |||
When executing query: | |||
""" | |||
MATCH (v:player{name: 'Tim Duncan'})-[e1:like*1..2]-(v2{name: 'Tony Parker'})-[e2:serve]-(v3{name: 'Spurs'}) | |||
MATCH (v:player{name: 'Tim Duncan'})-[e1:like*1..2]-(v2:player{name: 'Tony Parker'})-[e2:serve]-(v3:team{name: 'Spurs'}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix similar issue related to properties(v).tag.name
, nodes(p)[0].tag.name
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understood what you mean correctly, all tck cases calling the 'properties' function runs as expected for the time being. I didn't find any abnormal case, at least. Let me know if any tck case needs to be updated.
If we want to force all properties returned by this function to report tag information, we probabaly need to check with PD and open a new issue to refactor this function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For these tck cases, I added tags into them, otherwise errors would be reported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Essentially, it's all the same issue, that is, the tag must be specified to get the property.
"all tck cases calling the 'properties' function runs as expected for the time being." just because the test case is not covered the exception scenario.
* Return an semantic error if no tag is found for a property while validating a match. * Return an semantic error if no tag is found for a property while validating a match. * Add a tck case for the fixed bug. * commented out unused codes. * add tag in tck cases * fixing tck * updated tck cases to add missing cases that are supposed to be there. * Return an semantic error if no tag is found for a property while validating a match. * Add a tck case for the fixed bug. * commented out unused codes. * add tag in tck cases * fixing tck * updated tck cases to add missing cases that are supposed to be there. * update * update tck case. Co-authored-by: Sophie <[email protected]>
* Fix/find start error (#4771) * Fix find start error. * Fix test. Co-authored-by: Sophie <[email protected]> * Introduce JSON_EXTRACT function (#4743) * Introduce JSON_EXTRACT function close: #3513 Note, we don't support the path argument in this phase * address jievince's review commit removed the unecessary interface of construct Map from Value * Type handling Only primitive types are supported * Support depth1 nested * lint: fmt * ut: ctest, fixed wrong expression of Map * fix ut errors * tck: case for json_extract added Co-authored-by: Sophie <[email protected]> * Fix bug #1337 from ent (#4740) * Return an semantic error if no tag is found for a property while validating a match. * Return an semantic error if no tag is found for a property while validating a match. * Add a tck case for the fixed bug. * commented out unused codes. * add tag in tck cases * fixing tck * updated tck cases to add missing cases that are supposed to be there. * Return an semantic error if no tag is found for a property while validating a match. * Add a tck case for the fixed bug. * commented out unused codes. * add tag in tck cases * fixing tck * updated tck cases to add missing cases that are supposed to be there. * update * update tck case. Co-authored-by: Sophie <[email protected]> * Fix RollUpApplyExecutor (#4778) Co-authored-by: Sophie <[email protected]> * Fix mutil-match crash in optimization phase (#4780) fmt small fix small fix * fix subgraph step (#4776) * fix subgraph step * forbid function call in where clause * fix error Co-authored-by: shylock <[email protected]> Co-authored-by: Wey Gu <[email protected]> Co-authored-by: Cheng Xuntao <[email protected]> Co-authored-by: Yichen Wang <[email protected]> Co-authored-by: kyle.cao <[email protected]> Co-authored-by: jimingquan <[email protected]>
What type of PR is this?
What problem(s) does this PR solve?
Issue(s) number:
https://github.com/vesoft-inc/nebula-ent/issues/1337
Description:
Unexpected results returned by tag-less properties in the match clause.
How do you solve it?
All properties shall have tags. Return a semantic error message when there is none.
Special notes for your reviewer, ex. impact of this fix, design document, etc:
In addition to report errors on tag-less properties, I also commented out the previous
if branch
that is responsible formakeNodeSubFilter()
for tag-less properties.I tested other clauses like lookup and go. The
vertex.tag.property
pattern seems good. Errors are reported if the tag part is ommitted.Checklist:
Tests:
Affects:
The enterprise version.
Release notes:
Please confirm whether to be reflected in release notes and how to describe: