-
Notifications
You must be signed in to change notification settings - Fork 1.5k
feat: ScalarValue from String #8411
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
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.
LGTM! Thanks @QuenKar
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.
Is there anywhere else the code could use this change? if so I think it could be changed together.
let scalar = ScalarValue::from("foo".to_string()); | ||
assert_eq!(scalar, ScalarValue::Utf8(Some("foo".to_string()))); |
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.
Hmm, as we already implement From<&str>
for ScalarValue
, we can simply do this for a String
if we want to have a ScalarValue
for it:
let scalar = ScalarValue::from("foo".to_string().as_str());
assert_eq!(scalar, ScalarValue::Utf8(Some("foo".to_string())));
I think the only difference is From<String>
avoids copying the string content?
Do we have used as_str()
for String
in current code to create ScalarValue
? We probably can change to remove as_str()
.
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 find that there is no code similar to "foo".to_string().as_str()
or some_string.as_str()
or &some_string
or as_str().into()
in this use(But maybe I don't find all of them...
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.
One tricky might be removing From<&str>
implementqtion and seeing if something fails to compile.
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 think the only difference is From avoids copying the string content?
It avoids copying as well as makes creating ScalarValue
s easier to create / user (e.g. someone was confused as reported on #8380)
One tricky might be removing From<&str> implementqtion and seeing if something fails to compile.
I tried this and found there weren't any obvious examples in the codebase -- the more common pattern is ScalarValue::from("foo")
with a constant string
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 tried this and found there weren't any obvious examples in the codebase -- the more common pattern is
ScalarValue::from("foo")
with a constant string
Nice!
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.
Thank you @QuenKar and @Dandandan and @viirya
let scalar = ScalarValue::from("foo".to_string()); | ||
assert_eq!(scalar, ScalarValue::Utf8(Some("foo".to_string()))); |
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 think the only difference is From avoids copying the string content?
It avoids copying as well as makes creating ScalarValue
s easier to create / user (e.g. someone was confused as reported on #8380)
One tricky might be removing From<&str> implementqtion and seeing if something fails to compile.
I tried this and found there weren't any obvious examples in the codebase -- the more common pattern is ScalarValue::from("foo")
with a constant string
* feat: scalar from string * chore: cr comment
Which issue does this PR close?
Closes #8380 .
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?