Support both 0x01 and 0x02 as type for list of booleans in thrift metadata #7052
Conversation
parquet/src/thrift.rs
Outdated
| // 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]; |
There was a problem hiding this comment.
Minor nit: I'd find this easier to decode in my head if these were hex values, but that might just be me.
|
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 |
There was a problem hiding this comment.
Thanks @jhorstmann @tustvold and @etseidl
Given there is test coverage to ensure we don't regress so I think this one is good to go
| // Previous versions of the thrift specification said to use 0 and 1 inside collections, | ||
| // but that differed from existing implementations. | ||
| // The specification was updated in https://github.com/apache/thrift/commit/2c29c5665bc442e703480bb0ee60fe925ffe02e8. | ||
| // At least the go implementation seems to have followed the previously documented values. | ||
| match b { | ||
| 0x01 => Ok(true), |
There was a problem hiding this comment.
It seems the upstream thrift implementation may simply treat anything that is not 0x1 as false:
This doesn't look like it has changed for 9 years 🤔
There was a problem hiding this comment.
That seems to be the (non-compact) binary protocol, which uses different encodings and also different tags for the types. I was thinking of doing the same here though, the error handling does not add much value.
| // the defacto standard across large parts of the library became 1 instead. | ||
| // As a result, both values are now allowed. | ||
| // https://github.com/apache/thrift/blob/master/doc/specs/thrift-compact-protocol.md#list-and-set | ||
| 0x01 | 0x02 => Ok(TType::Bool), |
There was a problem hiding this comment.
Upstream thrift doesn't seem to support 0x02 for this 🤔
There was a problem hiding this comment.
I opened a PR just now: apache/thrift#3094
This might also affect parquet2 (currently unmaintained) and polars, and probably also other languages than rust.
There was a problem hiding this comment.
FYI @ritchie46 or @orlp -- we found a bug in reading arguably malformed parquet files created by go that @jhorstmann fixed in parquet-rs. I did a quick scan in polars and didn't find the equivalent code (though I don't understand how polars-parquet is structured enough to know really how to find it)
There was a problem hiding this comment.
I think I should forward that to our Parquet guy, @coastalwhite.
There was a problem hiding this comment.
Thanks for the heads-up. Also ported the fix to Polars 😄
|
Thanks again @jhorstmann and @etseidl |
This ports a change made upstream in apache/arrow-rs#7052
…adata (apache#7052) * Support both 0x01 and 0x02 as type for list of booleans * Also support 0 for false inside boolean collections * Use hex notation in tests
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:
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.