vustef commented on code in PR #8715:
URL: https://github.com/apache/arrow-rs/pull/8715#discussion_r2501021172
##########
parquet/src/arrow/schema/complex.rs:
##########
@@ -229,6 +244,20 @@ impl Visitor {
}
}
+ if rep_level == 0 && def_level == 0 {
+ for virtual_column in self.virtual_columns {
+ // Ensure this is actually a virtual column
+ assert!(
+ super::virtual_type::is_virtual_column(virtual_column),
+ "Field '{}' is not a virtual column. Virtual columns must
have extension type names starting with 'arrow.virtual.'",
+ virtual_column.name()
+ );
+ child_fields.push(virtual_column.clone());
+ let child = convert_virtual_field(virtual_column, rep_level,
def_level)?;
Review Comment:
Oh that reminds me. I wasn't sure whether in parquet we always have a schema
that has a struct at the top-level. So far I didn't encounter a case where it
was the case. Even a file with a single column had a struct on top, and then a
primitive column inside. So what I tried to do here was to add a field within
that struct.
Is that correct?
But also, are you saying that by the end of this process, the result is
going to be a `ParquetField` which is going to have a `field_type` of
`ParquetFieldType::Group`, and I can just match against that and add a new
`ParquetField` for virtual columns to the end of its `children` vector?
--
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]
