scovich commented on code in PR #9663:
URL: https://github.com/apache/arrow-rs/pull/9663#discussion_r3102932106
##########
parquet-variant-compute/src/shred_variant.rs:
##########
@@ -321,12 +328,19 @@ impl<'a> VariantToShreddedArrayVariantRowBuilder<'a> {
// If the variant is not an array, typed_value must be null.
// If the variant is an array, value must be null.
match variant {
- Variant::List(list) => {
+ Variant::List(ref list) => {
self.nulls.append_non_null();
- self.value_builder.append_null();
- self.typed_value_builder
- .append_value(&Variant::List(list))?;
- Ok(true)
+
+ // With `safe` cast option set to false, appending list of
wrong size to
+ // `typed_value_builder` of type `FixedSizeList` will result
in an error. In such a
+ // case, the provided list should be appended to the
`value_builder.
Review Comment:
> Overall, I think we'd not gain much by including FSL because it's so frail
and the use cause is not defined. Isn't the whole point of Variant is to host
semi-structured data, if we have fixed-len-something it'd be better to keep a
separate column for it. If fixed-length is a logical constraint rather than a
physical one, enforcement belongs downstream.
Agree. I just realized that somebody _could_ create a FSL of [shredded]
variant, if the use case just needs flexible typing of N list members. But that
also seems somewhat contrived, to have such strongly-typed structure but
sufficient uncertainty about the list element type to merit using variant.
--
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]
