Skip to content
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 parquet max_definition for non-null structs #246

Merged
merged 3 commits into from
May 4, 2021
Merged

Conversation

nevi-me
Copy link
Contributor

@nevi-me nevi-me commented May 2, 2021

Which issue does this PR close?

Closes #244 .

Rationale for this change

This fixes a bug

What changes are included in this PR?

Are there any user-facing changes?

No, changes made to crate-level structs, that are not publicly exposed

@codecov-commenter
Copy link

codecov-commenter commented May 2, 2021

Codecov Report

Merging #246 (f8cff98) into master (d008f31) will increase coverage by 0.01%.
The diff coverage is 81.96%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #246      +/-   ##
==========================================
+ Coverage   82.51%   82.53%   +0.01%     
==========================================
  Files         162      162              
  Lines       43655    43740      +85     
==========================================
+ Hits        36022    36099      +77     
- Misses       7633     7641       +8     
Impacted Files Coverage Δ
parquet/src/arrow/levels.rs 81.25% <73.17%> (-0.44%) ⬇️
parquet/src/arrow/arrow_writer.rs 98.42% <100.00%> (+0.09%) ⬆️
arrow/src/array/null.rs 86.66% <0.00%> (ø)
arrow/src/array/array.rs 76.07% <0.00%> (ø)
arrow/src/compute/kernels/sort.rs 94.41% <0.00%> (+0.08%) ⬆️
arrow/src/array/transform/fixed_binary.rs 84.21% <0.00%> (+5.26%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d008f31...f8cff98. Read the comment docs.

Copy link
Member

@jorgecarleitao jorgecarleitao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for taking this on, @nevi-me !

I started reviewing this. I can see where the problem may lie, but I am still trying to understand the logic.

@@ -311,11 +333,20 @@ impl LevelInfo {
} else if self.is_list {
// second exception, always increment after a list
self.max_definition + 1
} else if is_parent_struct && !self.is_nullable {
// if the parent is a non-null struct, don't increment
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am trying to wrap my head around this comment: self.is_nullable is the nullability of the parent in this case?

I would expect something like is_parent_struct_null computed from the nullability of the parent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, self is the parent, so if the parent is a null struct ...

Interestingly, I don't need the 'is_parent_steuct' variable, because '!self.is_list' means that self is a struct at this point in the code. I'll tweak the logic later tonight

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked this, trying to rely on the !self.is_list doesn't always work, so I'm leaving the logic as is for now.

@nevi-me nevi-me requested a review from alamb May 3, 2021 05:18
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't say I understand the intricacies of this logic, but I did read the PR and it seems to me that the PR is a step in the right direction and can be merged as is:

  1. Some tests pass now that did not pass previously
  2. The additional cases which may require more work are tracked by an issue.

let c = Int32Array::from(vec![1, 2, 3, 4, 5, 6]);
let b_data = ArrayDataBuilder::new(field_b.data_type().clone())
.len(6)
.null_bit_buffer(Buffer::from(vec![0b00100111]))
// .null_bit_buffer(Buffer::from(vec![0b00100111]))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok (given the test didn't pass previously anyways) so this isn't a regression

parquet/src/arrow/levels.rs Outdated Show resolved Hide resolved
list_field.is_nullable(),
)]
}
DataType::List(_) | DataType::LargeList(_) | DataType::Struct(_) => {
list_level.calculate_array_levels(&child_array, list_field)
list_level.calculate_array_levels(&child_array, list_field, false)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the data type is DataType::Struct(_), wouldn't is_parent_struct be true? I probably misunderstand

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, this is an immediate struct of a parent list, so it's false.

Copy link
Member

@jorgecarleitao jorgecarleitao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @nevi-me !

@nevi-me nevi-me merged commit 6a65543 into apache:master May 4, 2021
@nevi-me nevi-me deleted the i244 branch May 4, 2021 04:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unable to write non-null Arrow structs to Parquet
4 participants