-
Notifications
You must be signed in to change notification settings - Fork 1k
[Variant] add strict mode to cast_to_variant #8233
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: codephage2020 <[email protected]>
Signed-off-by: codephage2020 <[email protected]>
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.
Thanks for the fix! Left few comments
Signed-off-by: codephage2020 <[email protected]>
Signed-off-by: codephage2020 <[email protected]>
Thanks for your reviews @liamzwbao . All feedback implemented - ready for re-review! 🔍 CC @alamb . |
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.
Generally LGTM, couple questions
/// * `strict` - If true, return error on conversion failure. If false, insert null for failed conversions. | ||
pub fn cast_to_variant_with_options( | ||
input: &dyn Array, | ||
strict: bool, |
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 any possibility/risk that we may need additional options in the future? If so, it might be better to pass a struct? Or maybe we just deal with that if/when it comes?
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.
Yes, very good discovery. I have thought about this implementation. We can refactor this part in the next PR.
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.
lgtm! it’d be good to address @scovich’s comments as well.
run_test_non_strict( | ||
values, | ||
vec![ | ||
None, // Invalid timestamp becomes 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.
Just realized that for overflow value, we may need to convert it to Variant::Null
instead of None
like what we did for Decimal, see this comment for context. However, I don't think it should be in this PR, we could discuss and make them consistent later.
cc @alamb
Signed-off-by: codephage2020 <[email protected]> Co-authored-by: Ryan Johnson <[email protected]>
Signed-off-by: codephage2020 <[email protected]>
Signed-off-by: codephage2020 <[email protected]>
fn convert_timestamp( | ||
/// Options for controlling the behavior of `cast_to_variant_with_options`. | ||
#[derive(Debug, Clone, PartialEq, Eq)] | ||
pub struct CastOptions { |
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.
This looks quite similar to https://docs.rs/arrow/latest/arrow/compute/struct.CastOptions.html
However that seems to be defined in arrow-compute
[dependencies] |
Which issue does this PR close?
Date64
or Timestamp Values values #8155 .Rationale for this change
cast_to_variant will panic for values of Date64 / Timestamp that can not be converted to NaiveDate
What changes are included in this PR?
pub fn cast_to_variant_with_options(input: &dyn Array, strict: bool) -> Result<VariantArray, ArrowError>
Are these changes tested?
Yes.
Are there any user-facing changes?
no.