-
Notifications
You must be signed in to change notification settings - Fork 1.5k
feat: add SchemaProvider::table_type(table_name: &str) #16401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
InformationSchemaConfig::make_tables only needs the TableType not the whole TableProvider, and the former may require an expensive catalog operation to construct and the latter may not. This allows avoiding `SELECT * FROM information_schema.tables` having to make 1 of those potentially expensive operations per table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature makes sense to me -- thank you @epgif
I wonder if there is some way we can write a test for it (mostly to prevent it from being accidentally broken/changed in the future)
Maybe an example or something 🤔
I looked around for some tests implementing this interface that I could extend, but didn't find any. I meant to ask earlier but forgot: is there anything like that? It would be a big help if I had some previous tests to take inspiration from. Failing that, I'll take a stab at it anyway :) Thanks! |
/// returns `None`. Implementations for which this operation is cheap but [Self::table] is | ||
/// expensive can override this to improve operations that only need the type, e.g. | ||
/// `SELECT * FROM information_schema.tables`. | ||
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> { | |
async fn table_type(&self, name: &str) -> DataFusionResult<Option<TableType>> { |
/// expensive can override this to improve operations that only need the type, e.g. | ||
/// `SELECT * FROM information_schema.tables`. | ||
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> { | ||
self.table(name).await.map(|o| o.map(|t| t.table_type())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any way to avoid nested map
? perhaps flat_map
or and_then
? would me more readable IMHO
InformationSchemaConfig::make_tables only needs the TableType not the whole TableProvider, and the former may require an expensive catalog operation to construct and the latter may not.
This allows avoiding
SELECT * FROM information_schema.tables
having to make 1 of those potentially expensive operations per table.