-
Notifications
You must be signed in to change notification settings - Fork 721
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 reading nested lists from parquet files #1517
Conversation
ArrowType::List(list_field) => match list_field.data_type() { | ||
ArrowType::Struct(fields) => { | ||
field = fields.iter().find(|f| f.name() == part) | ||
} | ||
_ => field = Some(list_field.as_ref()), | ||
}, |
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 was tested by using the example in #1515. Not sure if it is easy to add a unit test.
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.
Shall we put the example parquet file into parquet-testing
too?
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 ideally we would construct a parquet file with this pattern programmatically (aka write it out in a test and then read it back in).
if that is not possible / feasible, adding an example in parquet-testing would be second best
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.
Sounds good. Let me try to make one. Thanks.
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 for driving this @viirya
ArrowType::List(list_field) => match list_field.data_type() { | ||
ArrowType::Struct(fields) => { | ||
field = fields.iter().find(|f| f.name() == part) | ||
} | ||
_ => field = Some(list_field.as_ref()), | ||
}, |
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 ideally we would construct a parquet file with this pattern programmatically (aka write it out in a test and then read it back in).
if that is not possible / feasible, adding an example in parquet-testing would be second best
Interesting, I cannot reproduce the Parquet file by writing a simple Parquet file in test. The main difference is: For the original Parquet file, the path to the
Because I use the same message type to write out a Parquet file in test. But when I read it back. For the same
For the first I checked the arrow schema for the Parquet file and the one I wrote in test, they are the same. So I am currently not sure why the column paths for same column Update: The different column path should not be an issue. The message type from the issue and the one I get from the Parquet file using arrow-rs, are the the same. I think it is because of that. But both cases we should be able to read them. |
Let me dig why there is the difference. |
let item_reader = self | ||
.dispatch(item_type.clone(), &new_context) | ||
.unwrap() | ||
.unwrap(); |
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.
When a column is not included, dispatch
will return None. unwrap
here will get unexpected error.
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 found using a whitespace blind diff made the changes easier to understand: https://github.com/apache/arrow-rs/pull/1517/files?w=1
message table { | ||
REPEATED group table_info { | ||
REQUIRED BYTE_ARRAY name; | ||
REPEATED group cols { | ||
REQUIRED BYTE_ARRAY name; | ||
REQUIRED INT32 type; | ||
OPTIONAL INT32 length; | ||
} | ||
REPEATED group tags { | ||
REQUIRED BYTE_ARRAY name; | ||
REQUIRED INT32 type; | ||
OPTIONAL INT32 length; | ||
} | ||
} | ||
} | ||
"; |
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 message type is copied from the issue.
Codecov Report
@@ Coverage Diff @@
## master #1517 +/- ##
==========================================
+ Coverage 82.68% 82.79% +0.10%
==========================================
Files 188 190 +2
Lines 54361 54717 +356
==========================================
+ Hits 44951 45301 +350
- Misses 9410 9416 +6
Continue to review full report at Codecov.
|
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.
Looks good to me -- thank you @viirya
@@ -2268,4 +2272,67 @@ mod tests { | |||
&PrimitiveArray::<ArrowInt32>::from(vec![Some(3), Some(4)]) | |||
); | |||
} | |||
|
|||
#[test] | |||
fn test_nested_lists() { |
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 tested running this test without the rest of the code change in this PR and I got:
---- arrow::array_reader::tests::test_nested_lists stdout ----
thread 'arrow::array_reader::tests::test_nested_lists' panicked at 'called `Option::unwrap()` on a `None` value', parquet/src/arrow/array_reader/builder.rs:327:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
let item_reader = self | ||
.dispatch(item_type.clone(), &new_context) | ||
.unwrap() | ||
.unwrap(); |
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 found using a whitespace blind diff made the changes easier to understand: https://github.com/apache/arrow-rs/pull/1517/files?w=1
Thanks @viirya |
Thank you @alamb ! |
Which issue does this PR close?
Closes #1515.
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?