test(parquet): replace InMemoryArrayReader with PrimitiveArrayReader in tests#9847
Merged
alamb merged 1 commit intoapache:mainfrom May 5, 2026
Merged
Conversation
`InMemoryArrayReader` coupled a column's in-memory representation (an Arrow array) with its storage representation (def/rep levels) by assuming a 1:1 mapping between array elements and levels. This held when list readers consumed fully-padded child arrays — one element per level, nulls included. Upcoming work pushes null filtering from `ListArrayReader` down into the child reader at the storage level, breaking that 1:1 assumption: the child returns fewer array elements than levels, and the mapping between them depends on the filtering logic itself. Keeping the mock would mean reimplementing that logic: testing filtered output against a second, hand-rolled filter. Replace `InMemoryArrayReader` with real `PrimitiveArrayReader` instances backed by in-memory Parquet pages. Tests now accept raw non-null values and levels (matching what Parquet actually stores) and exercise the production `RecordReader` path. Signed-off-by: Hippolyte Barraud <hippolyte.barraud@datadoghq.com>
alamb
changed the title
InMemoryArrayReader with PrimitiveArrayReaderInMemoryArrayReader with PrimitiveArrayReader in tests
alamb
approved these changes
May 1, 2026
Contributor
alamb
left a comment
alamb
left a comment
There was a problem hiding this comment.
Thanks @HippoBaro -- looks good to me. I had some API / readability suggestions but I don't think they are required. We can do them as a follow on PR (or never)
| /// `values` must contain only the non-null values (entries where | ||
| /// `def_levels[i] == max_def_level`), in order, as Parquet encodes them. | ||
| pub fn make_int32_page_reader( | ||
| values: &[i32], |
Contributor
There was a problem hiding this comment.
I double checked that all callsites actually used DataType::Int32 which makes sense to me
| Some(vec![0, 1, 2, 3, 1]), | ||
| Some(vec![0, 1, 1, 1, 1]), | ||
| ); | ||
| let array_reader_1 = make_int32_page_reader(&[4], &[0, 1, 2, 3, 1], &[0, 1, 1, 1, 1], 3, 1); |
Contributor
There was a problem hiding this comment.
As an API suggestion (maybe for another PR, not required):
I would personally find this much easier to understand if the fields were named so I didn't have to refer to make_int32_page_reader to figure out what&[0, 1, 2, 3, 1] and &[0, 1, 1, 1, 1] meant.
Perhaps we could do this with an builder in the test. Something like this perhaps:
let array_reader_1 = TestArrayReaderBuilder::new()
.with_non_null_i32_values(&[4]) // <-- this is especially non obvous if you are used to normal Arrow arrays
.with_def_levels(&[0, 1, 2, 3, 1])
.with_rep_levels(&[0, 1, 1, 1, 1])
.with_max_def_level(3)
.with_max_rep_level(1)
.build()
Contributor
Author
There was a problem hiding this comment.
Oh that would be lovely
Contributor
There was a problem hiding this comment.
- Filed an issue to track: Improve parquet ArrayReaderBuilder tests #9921
| /// `RecordReader` code path (including selective padding when a parent | ||
| /// `ListArrayReader` calls `enable_selective_padding`). | ||
| /// | ||
| /// `values` must contain only the non-null values (entries where |
Contributor
|
Thanks again @HippoBaro |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
InMemoryArrayReadercouples a column's in-memory representation (an Arrow array) with its storage representation (def/rep levels) and assumes a 1:1 mapping between array elements and levels. This holds when list readers consume fully-padded child arrays — one element per level, nulls included.Upcoming work (see #9848) pushes null filtering from
ListArrayReaderdown into the child reader at the storage level, breaking that 1:1 assumption: the child returns fewer array elements than levels, and the mapping between them depends on the filtering logic itself. Keeping the mock would mean reimplementing that logic: testing filtered output against a second, hand-rolled filter.What changes are included in this PR?
Replace
InMemoryArrayReaderwith realPrimitiveArrayReaderinstances backed by in-memory Parquet pages. Tests now accept raw non-null values and levels (matching what Parquet actually stores) and exercise the productionRecordReaderpath.Are these changes tested?
This is a net positive in test coverage. The existing tests now exercise real readers instead of in-memory and already-dense representations.
Are there any user-facing changes?
None.