scovich commented on PR #8093: URL: https://github.com/apache/arrow-rs/pull/8093#issuecomment-3200535143
> 1. VariantArray::value() to return Option to properly distinguish SQL NULL vs JSON null > 4\. Split AllNull handling into separate variants for top-level vs shredded contexts My understanding is that the array's null buffer and `is_null` method should always say whether the value is SQL null, and the `value` method should always return _something_ if invoked. So returning `Variant::Null` for null/null combo should always be correct, in that sense. When building a top-level variant, we could intersect the null masks of the `value` and `typed_value` fields, and verify that the result is strictly a subset of the variant's own null mask. Similar to the validation performed by `StructArray` for non-nullable fields inside a nullable struct. When using e.g. `variant_get` to project a variant object field as a new `VariantArray`, we again need to intersect the null masks of the `value` and `typed_value` fields, to form the basis of the null mask for the resulting `VariantArray`. But we _also_ need to union in all ancestors' null masks along the path `variant_get` followed to reach the field -- same as we'd have to do when projecting a field from a `StructArray`. Kind of complicated/subtle... took a long time to wrap my head around even the `StructArray` version, let alone the `VariantArray` extensions. -- 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: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
