scovich commented on PR #10015: URL: https://github.com/apache/arrow-rs/pull/10015#issuecomment-4633590267
> I added uuid support to `canonicalize_and_verify_field`. It will add uuid ext type on read for `VariantArray` that come from different writers that potentially omit it. > > I'm not sure about that last change, so let's think about it 🤓 If we're in the business of injecting UUID extension type at all, this _seems_ like an important piece of the puzzle? > Parquet writer recursively travels through each field and runs `arrow_to_parquet_type` on it, so nested fields ext type is preserved. (I added a nested uuid unit test that passes - [70d2242](https://github.com/apache/arrow-rs/commit/70d2242b5615e70151d7926cd03e688e189a2c00)) > > [](https://github.com/apache/arrow-rs/blob/e5e66fa05ce986fa6a3f61c36c11ff6b476cb76c/parquet/src/arrow/schema/mod.rs#L776-L783) Not sure I follow? In the original version of this PR, `VariantArray::from_parts` and `ShreddedVariantFieldArray::from_parts` injected the UUID extension type. I had missed the latter, which probably explains why the new nested UUID unit test passes. But how does that relate to `arrow_to_parquet_type`? If nobody calls `from_parts` along the way, then the type won't be injected. At this point we have: * Anybody who drills into a shredded variant array will get UUID extension (due to `from_parts`) * Anybody who reads shredded variant will get UUID extension (due to `canonicalize_and_verify_field`) Is it possible to send a shredded variant array to the parquet writer that bypasses both those paths? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
