Zouxxyy commented on code in PR #7073:
URL: https://github.com/apache/paimon/pull/7073#discussion_r2702085797
##########
paimon-common/src/main/java/org/apache/paimon/data/variant/VariantExtraction.java:
##########
@@ -18,28 +18,36 @@
package org.apache.paimon.data.variant;
+import org.apache.paimon.annotation.Experimental;
import org.apache.paimon.types.DataField;
import java.io.Serializable;
+import java.util.Arrays;
import java.util.List;
+import java.util.Objects;
-/** Variant access information for a variant column. */
-public class VariantAccessInfo implements Serializable {
+/** Variant extraction information that describes fields extraction from a
variant column. */
+@Experimental
+public class VariantExtraction implements Serializable {
private static final long serialVersionUID = 1L;
- // The name of the variant column.
- private final String columnName;
+ /**
+ * Returns the path to the variant column. For top-level variant columns,
this is a single
+ * element array containing the column name. For nested variant columns
within structs, this is
+ * an array representing the path (e.g., ["structCol", "innerStruct",
"variantCol"]).
+ */
+ private final String[] columnName;
Review Comment:
I still believe that making `extractedFields` as a field of `VariantType` is
a better approach. This offers the following advantages:
- There's no need to keep adding `withVariantExtractions` in the API, as it
will be propagated through the `readType`.
- It natively supports nested types (similar to how I previously changed
`projection[][]` into a `RowType`).
- It also makes implementing nested reading on the reader side much cleaner
and easier.
Alternatively, we could directly convert `VariantType` into the `RowType`
resulting from shredding reads. This approach would require the RowType to be
marked—via a specific field or attribute—as originating from a 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]
