-
Notifications
You must be signed in to change notification settings - Fork 312
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: json_path_exists null results #4881
base: main
Are you sure you want to change the base?
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4881 +/- ##
==========================================
- Coverage 84.18% 83.98% -0.20%
==========================================
Files 1136 1137 +1
Lines 208585 210255 +1670
==========================================
+ Hits 175597 176592 +995
- Misses 32988 33663 +675 |
Thanks @Kev1n8 ❤️ |
match json.data_type() { | ||
ConcreteDataType::Binary(_) => { |
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.
We should use jsons.data_type()
because the data type of ValueRef::Null
isn't Binary
. But we can match json
and handle ValueRef::Binary
and ValueRef::Null
.
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 your point, but I’m curious about how we would handle cases where some items in the array are ValueRef::Null
while others are not. Or, all items' datatype are supposed to be the same?
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.
Items in an array have the same data type. You can treat null as the same data type as other items in this array. Like None::<String>
. But ValueRef
itself doesn't carry the type information now.
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.
Okay, I'll update the code.
To be clear, I'd like to specify the expected results of all SQLs below:
Please let me know if anything is incorrect. |
looks good |
// Any null args existence causes the result to be NULL. | ||
(ConcreteDataType::Null(_), ConcreteDataType::String(_)) => results.push_nulls(size), | ||
(ConcreteDataType::Binary(_), ConcreteDataType::Null(_)) => results.push_nulls(size), | ||
(ConcreteDataType::Null(_), ConcreteDataType::Null(_)) => results.push_nulls(size), |
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.
According to the sqlness tests, this should be the only change that needs to be done?
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.
There are 2 major changes: function signatures and datatype cases.
- I believe function signature changes matter for accepting null type. I've tested if, with only
Exact(vec![Json, String])
, system will throw error when the signature does not match. - Apart from "this" change, I think the error handlers also make sense, while the original simply push a
None
into results when there's a parsing or casting error.
Reduced some unnecessary checks. Please check out. |
I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
Closes #4865.
What's changed and what's your intention?
As explained in referred issue, the result should be
null
if any of the parameters isnull
.Checklist