alamb commented on code in PR #8521:
URL: https://github.com/apache/arrow-rs/pull/8521#discussion_r2395990467
##########
parquet-variant-compute/src/arrow_to_variant.rs:
##########
@@ -38,6 +38,98 @@ use parquet_variant::{
use std::collections::HashMap;
use std::ops::Range;
+// ============================================================================
+// Shared traits and helpers for Arrow-to-Variant conversion
+// ============================================================================
+
+/// Zero-cost trait for converting Arrow array values to Variant
+pub(crate) trait ArrowToVariant: Array {
+ fn append_to_variant_builder(
+ &self,
+ builder: &mut impl VariantBuilderExt,
+ index: usize,
+ ) -> Result<(), ArrowError>;
+}
+
+/// Macro to define ArrowToVariant implementations with optional value
transformation
+macro_rules! define_arrow_to_variant {
Review Comment:
- Here is the PR https://github.com/apache/arrow-rs/pull/8532
> I guess variant_get could be seen as a superset of a hypothetical
cast_variant_to_arrow function that is an inverse of cast_[arrow_]to_variant?
Yes, I think that is a good way to think about it. I don't think we should
add `cast_to_variant_to_arrow` at this time (I was very confused)
> And, for good measure, some of the conversions probably should move to
type_conversions module, and I don't know where the ListLikeArray trait should
live?
Or maybe we could consolidate the conversions into `arrow_to_variant` or
`variant_to_arrow` 🤔
--
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]
