-
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
Changes from 6 commits
1a824a4
cf82ca1
4de4900
dccb720
67488ab
b1b0576
099584e
8bec593
4233b58
d7d0145
eb24755
ee22dc0
f9b59ae
5737b08
5d8a013
da282af
e7789ba
111b104
58f3363
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -128,7 +128,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"}) | ||
RETURN type(r) AS Type, v2.team.name AS Name | ||
""" | ||
Then the result should be, in any order: | ||
|
@@ -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 commentThe 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:
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. Maybe open an issue on this? |
||
WHERE r.start_year <= 2005 AND r.end_year >= 2005 | ||
RETURN r.start_year AS Start_Year, r.end_year AS Start_Year | ||
""" | ||
|
@@ -514,11 +514,6 @@ Feature: Basic match | |
MATCH (v) 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: | ||
""" | ||
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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. Sure. Relocated this case to a new scenario |
||
""" | ||
MATCH (v:player:bachelor) RETURN v | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 commentThe reason will be displayed to describe this comment to others. Learn more. Please fix similar issue related to There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe 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. |
||
RETURN e1, e2 | ||
""" | ||
Then the result should be, in any order, with relax comparison: | ||
|
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.