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

Support both 0x01 and 0x02 as type for list of booleans in thrift metadata #7052

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jhorstmann
Copy link
Contributor

@jhorstmann jhorstmann commented Jan 31, 2025

Which issue does this PR close?

Rationale for this change

The thrift documentation for lists of booleans was recently updated to clarify encoding of booleans:

For historical and compatibility reasons, a reader should be capable to deal with both cases. The only valid value in the original spec was 2, but due to an widespread implementation bug the defacto standard across large parts of the library became 1 instead. As a result, both values are now allowed.

At least the go implementation seems to encode the type as 0x02

What changes are included in this PR?

Be a bit more lenient and accept both types.

Are there any user-facing changes?

No, this should be a compatible change. Might even be worth backparting to a bugfix release.

@github-actions github-actions bot added the parquet Changes to the parquet crate label Jan 31, 2025
Copy link
Contributor

@etseidl etseidl left a comment

Choose a reason for hiding this comment

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

Looks reasonable. Thanks!

// Boolean collection type encoded as 0x01, as used by this crate when writing.
// Values encoded as 1 (true) or 2 (false) as in the current version of the thrift
// documentation.
let bytes = vec![25, 33, 2, 1, 25, 8, 25, 8, 21, 0, 0];
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor nit: I'd find this easier to decode in my head if these were hex values, but that might just be me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea!

@tustvold
Copy link
Contributor

tustvold commented Feb 1, 2025

Given this reader was copied from the upstream thrift impl, which we still use in some places, I wonder if this change needs to be made there as well?

@jhorstmann
Copy link
Contributor Author

Given this reader was copied from the upstream thrift impl, which we still use in some places, I wonder if this change needs to be made there as well?

You are right, I hoped this might have been fixed already upstream. I'll look into providing a bugfix there too.

I think inside arrow-rs the upstream TCompactInputProtocol is only used for reading page headers, which luckily do not contain collections of boolean (boolean fields are unaffected by this problem).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parquet Changes to the parquet crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Querying Parquet file specifically with a predicate returns invalid data error but works in other situations
3 participants