friendlymatthew commented on code in PR #17242:
URL: https://github.com/apache/datafusion/pull/17242#discussion_r2302043230
##########
datafusion-examples/examples/parquet_exec_visitor.rs:
##########
@@ -98,9 +98,11 @@ impl ExecutionPlanVisitor for ParquetExecVisitor {
fn pre_visit(&mut self, plan: &dyn ExecutionPlan) -> Result<bool,
Self::Error> {
// If needed match on a specific `ExecutionPlan` node type
if let Some(data_source_exec) =
plan.as_any().downcast_ref::<DataSourceExec>() {
- if let Some((file_config, _)) =
+ if let Some(parquet_source) =
data_source_exec.downcast_to_file_source::<ParquetSource>()
{
+ let file_config = parquet_source.config();
+
self.file_groups = Some(file_config.file_groups.clone());
Review Comment:
Hm, interesting point. With
[5d4e834](https://github.com/apache/datafusion/pull/17242/commits/5d4e834c1839a130372243514bbee31ae03a986e),
I'm starting to see a stratified API for `T: FileSource`, where certain
methods are called directly on `T` and others via `T::FileScanConfig`.
The statistics getters were the only blatant cases where it was better
served to have those functions live on `T`. I think having a `file_groups()` on
`T` makes sense, but so does a lot of the functions that live in
`T::FileScanConfig`.
Will think more about this
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
