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
Break datafusion-catalog code into its own crate #11182
Is your feature request related to a problem or challenge?
As we start thinking of adding new catalog support in DataFusion for example, @goldmedal tried to do this for DynamicFileCatalog in #11035 , the current code structure requires that any such implementation be in datafusion/core which is already quite large and monolithic
Also, I think long term it would be a more sustainable structure if we can move ListingTable out of the core as well
However, this move is not likely possible until we move table provider and related catalog traits out of the core.
Also, if we could split up datafusion core more, it would be easier for people to use DataFusion as a smaller embedded library (aka not bring in file format support if they didn't need it)
Describe the solution you'd like
Ideally I would like the following traits / code moved into a datafusion-catalog crate:
log::info!("Unable to register default AvroFormat: {e}")
};
// register built in functions
functions::register_all(&mut new_self)
.expect("can not register built in functions");
// register crate of array expressions (if enabled)
#[cfg(feature = "array_expressions")]
functions_array::register_all(&mut new_self)
.expect("can not register array expressions");
functions_aggregate::register_all(&mut new_self)
.expect("can not register aggregate functions");
new_self
One way to handle this would be to allow constructing SessionState with the minimal built in features, and have a function in SessionContext like SessionContext::register_built_ins that would register things like listing table, information schema, etc.
That way it would still be easy to use DataFusion with a minimal SessionState but also easily register all the built in extensions 🤔
@alamb I took a stab at moving parquet functionality into a datafusion-parquet crate (#11188) , and I ran into similar challenges you highlight here. I think to accomplish these goals core will need to be refactored into a number of different crates to avoid circular dependencies and allow core to still offer a batteries included experience.
I think to accomplish these goals core will need to be refactored into a number of different crates to avoid circular dependencies and allow core to still offer a batteries included experience.
I agree with this entirely
The center of the knot is SessionState I think -- figuring out how to get that out of the core is likely key to breaking things up reasonably
The more I think about this the more I think trying to make SessionState a container that doesn't have all the optional features (like parquet support) by default makes sense
So like
let session_state = SessionState::new();// no table providers, etc// install standard built in table providersSessionContex::install_built_in(&mut session_state);// now session_state has them here
The more I think about this the more I think trying to make SessionState a container that doesn't have all the optional features (like parquet support) by default makes sense
So like
let session_state = SessionState::new();// no table providers, etc// install standard built in table providersSessionContex::install_built_in(&mut session_state);// now session_state has them here
Activity
alamb commentedon Jun 30, 2024
I looked into this --
One of the major challenges is that
SessionState'sconstructor basically installs the "pre-provided" functionality (like data sources, etcdatafusion/datafusion/core/src/execution/session_state.rs
Lines 190 to 295 in 78055fe
One way to handle this would be to allow constructing SessionState with the minimal built in features, and have a function in
SessionContextlikeSessionContext::register_built_insthat would register things like listing table, information schema, etc.That way it would still be easy to use DataFusion with a minimal SessionState but also easily register all the built in extensions 🤔
alamb commentedon Jun 30, 2024
I made #11183 to start breaking apart the API and implementation -- there is still a ways to go
devinjdangelo commentedon Jul 1, 2024
@alamb I took a stab at moving parquet functionality into a datafusion-parquet crate (#11188) , and I ran into similar challenges you highlight here. I think to accomplish these goals
corewill need to be refactored into a number of different crates to avoid circular dependencies and allow core to still offer a batteries included experience.alamb commentedon Jul 1, 2024
I agree with this entirely
The center of the knot is SessionState I think -- figuring out how to get that out of the core is likely key to breaking things up reasonably
alamb commentedon Jul 1, 2024
The more I think about this the more I think trying to make
SessionStatea container that doesn't have all the optional features (like parquet support) by default makes senseSo like
alamb commentedon Jul 7, 2024
I filed #11320 to track this idea
alamb commentedon Oct 15, 2025
I think this is basically complete, so closing it down