CurtHagenlocher opened a new issue, #448: URL: https://github.com/apache/arrow-dotnet/issues/448
### Describe the bug, including details regarding any error messages, version, and platform. `VariantArray` accepts `binary`, `large_binary` or `binary_view` for its `metadata` and `value` fields, at the top level and inside shredded element groups (`VariantExtensionDefinition.FindBinaryFieldIndex`, `ShredSchema.IsElementGroupStruct`). `ShredSchema.FromArrowType` also maps `large_utf8` and `large_binary` `typed_value` columns. The shredding-aware readers in `Apache.Arrow.Operations.Shredding` (`ShreddedVariant`, `ShreddedObject`, `ShreddedArray`) cast those columns to `BinaryArray` / `StringArray`, so any other representation throws `InvalidCastException`. This affects: - `GetLogicalVariantValue` on any such column, shredded or not. For an unshredded `large_binary` column the core `VariantArray.GetVariantValue` works, but `GetLogicalVariantValue` throws. - `ShreddedVariant.GetString()` / `GetBinaryBytes()` on `large_utf8` / `large_binary` typed columns. - Residual reads in `ShreddedObject` / `ShreddedArray`, `TryGetResidualReader`, etc. Expected: the readers accept every storage type that `VariantArray` and `ShredSchema` accept. Found while reviewing #447, whose new array-level entry points go through these readers. ### Component(s) C# -- 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]
