You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add builder API for CreateExternalTable to reduce redundancy and make the code easier to understand #19039
Is your feature request related to a problem or challenge?
While reviewing #18971. I noticed many examples like this over the codbase
let cmd = CreateExternalTable{
name,
location,file_type:"parquet".to_string(),schema:Arc::new(DFSchema::empty()),table_partition_cols:vec![],if_not_exists:false,or_replace:false,temporary:false,definition:None,order_exprs:vec![],unbounded:false,options:HashMap::new(),constraints:Constraints::default(),column_defaults:HashMap::new(),};
This is non ideal for several reasons:
It is verbose (most of the fields are the defaults)
It makes it hard to see what fields are actually overridden vs which are the defaults
Describe the solution you'd like
instead of having to provide values for all fields, most of which are the default values, I think it would be nice to have a well commented builder API
Describe alternatives you've considered
I suggest adding a CrateExternalTableBuilder and replace the above code it with something like this
let cmd = CreateExternalTable::builder().with_name(name).with_location(location).with_file_type("parquet").with_schema(schema).build()?
It may make sense to have required parameters be verified by the compiler like this
let cmd = CreateExternalTable::builder(name, location,"parquet", schema).build()?
I think this is a good issue for someone who wants to learn how the code works and get a contribution
I think an LLM can probably pound it out pretty fast too, so a large point of me writing this issue is to help others get some experience with the DataFusion codebase
I’ve reviewed the current CreateExternalTable struct and the use cases where many default fields are repeated. Adding a CreateExternalTableBuilder makes sense to simplify construction and make overridden fields clearer.
Before I start, could you confirm two things:
Should the builder enforce required fields through its constructor (e.g., name, location, file_type, schema)?
Should the builder live in the same module as CreateExternalTable, or would you prefer placing it in a separate builder module?
If this approach aligns with your expectations, I’m happy to proceed. Thanks!
This enforces the 4 core required fields at compile-time, while optional fields can be set via .with_*() methods (following the pattern I saw in DataFusionErrorBuilder).
Activity
alamb commentedon Dec 1, 2025
I think this is a good issue for someone who wants to learn how the code works and get a contribution
I think an LLM can probably pound it out pretty fast too, so a large point of me writing this issue is to help others get some experience with the DataFusion codebase
atifxcode commentedon Dec 2, 2025
Hi @alamb, I would like to work on this issue.
I’ve reviewed the current
CreateExternalTablestruct and the use cases where many default fields are repeated. Adding aCreateExternalTableBuildermakes sense to simplify construction and make overridden fields clearer.Before I start, could you confirm two things:
CreateExternalTable, or would you prefer placing it in a separatebuildermodule?If this approach aligns with your expectations, I’m happy to proceed. Thanks!
feat: Add builder API for CreateExternalTable to reduce verbosity
AryanBagade commentedon Dec 3, 2025
Hey @alamb
I have created a PR and implemented a builder API, following ur second approach (required parameters in the constructor)
I went with:
This enforces the 4 core required fields at compile-time, while optional fields can be set via .with_*() methods (following the pattern I saw in DataFusionErrorBuilder).
feat: Add builder API for CreateExternalTable to reduce verbosity (#1…