Skip to content
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

enhance match attribute filter #3272

Merged
merged 6 commits into from
Nov 22, 2021

Conversation

nevermore3
Copy link
Contributor

What type of PR is this?

enhancement

What does this PR do?

close #3270

Which issue(s)/PR(s) this PR relates to?

Special notes for your reviewer, ex. impact of this fix, etc:

Additional context:

Checklist:

Release notes: `

@Shylock-Hg
Copy link
Contributor

Add test cases.

@nevermore3 nevermore3 added type/enhancement Type: make the code neat or more efficient ready-for-testing PR: ready for the CI test labels Nov 4, 2021
@nevermore3 nevermore3 force-pushed the enhance_match_filter branch 2 times, most recently from 5c9ce6c to 9314898 Compare November 4, 2021 09:29
| e |
When executing query:
"""
match (v:player{age:"24"-1}) return v
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will report error in cypher.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines +166 to +169
MapExpression* props() { return props_; }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete const?

Comment on lines 527 to 529
StatusOr<Expression *> MatchValidator::makeSubFilter(const std::string &alias,
const MapExpression *map,
const std::string &label) const {
MapExpression *map,
const std::string &label) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expressions related implementation changes should not change the Interface of the Validator.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to rewrite the expression after fold into the mapexpression

@nevermore3 nevermore3 force-pushed the enhance_match_filter branch 2 times, most recently from 002cfc3 to 70099cd Compare November 8, 2021 06:07

Scenario: toInteger
When executing query:
"""
YIELD [toInteger(true), toInteger(false), toInteger(1), toInteger(3.14),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toInteger(false), toInteger(true) will report error in opencypher, other modified cases too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should keep the origin case, and add new one to test the origin function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i know, but the result of origin case is wrong, and the modified logic test has been covered

@codecov-commenter
Copy link

Codecov Report

Merging #3272 (70099cd) into master (58f0b44) will decrease coverage by 0.00%.
The diff coverage is 71.42%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3272      +/-   ##
==========================================
- Coverage   85.24%   85.23%   -0.01%     
==========================================
  Files        1295     1295              
  Lines      118190   118210      +20     
==========================================
+ Hits       100748   100762      +14     
- Misses      17442    17448       +6     
Impacted Files Coverage Δ
src/graph/validator/MatchValidator.h 100.00% <ø> (ø)
src/graph/visitor/test/FilterTransformTest.cpp 100.00% <ø> (ø)
src/parser/MatchSentence.h 100.00% <ø> (ø)
src/graph/validator/MatchValidator.cpp 86.74% <55.55%> (-0.53%) ⬇️
src/graph/visitor/FoldConstantExprVisitor.cpp 85.12% <100.00%> (+0.19%) ⬆️
src/meta/processors/parts/GetSpaceProcessor.cpp 60.60% <0.00%> (-18.19%) ⬇️
src/graph/planner/Planner.cpp 75.00% <0.00%> (-5.00%) ⬇️
...eta/processors/session/SessionManagerProcessor.cpp 74.19% <0.00%> (-4.52%) ⬇️
src/common/expression/LogicalExpression.cpp 91.66% <0.00%> (-1.73%) ⬇️
src/graph/session/GraphSessionManager.cpp 79.88% <0.00%> (-1.73%) ⬇️
... and 25 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 58f0b44...70099cd. Read the comment docs.

CPWstatic
CPWstatic previously approved these changes Nov 18, 2021
Copy link
Contributor

@CPWstatic CPWstatic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Please fix the conflicts.

@Sophie-Xie Sophie-Xie removed the request for review from yixinglu November 22, 2021 02:31
Copy link
Contributor

@yixinglu yixinglu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@cangfengzhs cangfengzhs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. But, I have a small question. Is it reasonable to expose BAT_TYPE to users? I haven't learned about GQL and opencypher. If they are like this, that's OK. But if they are not like this, is it necessary for us to standardize the null type we return to user? After all, our Value has many kinds of null type.

@CPWstatic CPWstatic merged commit b575189 into vesoft-inc:master Nov 22, 2021
@jievince
Copy link
Contributor

jievince commented Nov 22, 2021

LGTM. But, I have a small question. Is it reasonable to expose BAT_TYPE to users? I haven't learned about GQL and opencypher. If they are like this, that's OK. But if they are not like this, is it necessary for us to standardize the null type we return to user? After all, our Value has many kinds of null type.

Neither of them return BAD_TYPE, so the NULL, BAD_TYPE should be reconsidered

@czpmango
Copy link
Contributor

czpmango commented Jan 5, 2022

LGTM. But, I have a small question. Is it reasonable to expose BAT_TYPE to users? I haven't learned about GQL and opencypher. If they are like this, that's OK. But if they are not like this, is it necessary for us to standardize the null type we return to user? After all, our Value has many kinds of null type.

All bad nulls is actually just an error with an error message. It may be more reasonable to provide a Value overload with customizable error messages, bcz current expressions’ ability to report and transmit errors is very limited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-testing PR: ready for the CI test type/enhancement Type: make the code neat or more efficient
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MATCH Attribute filtering does not support negative numbers
8 participants