-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
implement drop view
#3267
implement drop view
#3267
Conversation
@DaltonModlin may be interested in this. |
Codecov Report
@@ Coverage Diff @@
## master #3267 +/- ##
==========================================
- Coverage 85.48% 85.47% -0.02%
==========================================
Files 294 294
Lines 54072 54130 +58
==========================================
+ Hits 46223 46267 +44
- Misses 7849 7863 +14
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Functionality plus basic tests and docs added |
One thing I didn't do in this PR: re-export the new datafusion_expr::logical_plan::DropView struct via the "legacy" logical_plan module in core (datafusion::logical_plan:: ..). Should I re-export it or does legacy in this case mean that no new re-exports should happen there? https://github.com/apache/arrow-datafusion/blob/master/datafusion/core/src/logical_plan/mod.rs#L18 Alternatively, should we create an issue to remove this legacy re-exporting? |
We do have an issue already for this - #2683 We may want to deprecate this module for one release and then remove in the next. |
DROP TABLE IF EXISTS nonexistent_table; | ||
``` | ||
|
||
## DROP VIEW |
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.
Thanks for improving the docs!
@andygrove This is ready. Let me know what I can do to help get it committed. Thanks! |
@alamb is there someone that's suitable to review this and give feedback? this PR is blocking progress on other issues and it's not getting a review :( and I'm not sure how to proceed |
SOrry @kmitchener -- I will review it now |
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 looks great @kmitchener -- thank you and I apologize again for the delay in review
schema: DFSchemaRef::new(DFSchema::empty()), | ||
})), | ||
_ => Err(DataFusionError::NotImplemented( | ||
"Only `DROP TABLE/VIEW ...` statement is supported currently" |
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.
👍
@@ -1019,6 +1030,17 @@ pub struct DropTable { | |||
pub schema: DFSchemaRef, | |||
} | |||
|
|||
/// Drops a view. |
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.
Not for this PR, but it seems to me like requiring new LogicalPlan
nodes for each type of DDL (CREATE
, DROP
, etc) is somewhat cumbersome. Maybe we can eventually refactor type of thing into LogicalPlan::DDL(DDL)
and keep all the DDL related structs in their own structure. I'll file a follow on ticket for this
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.
Filed #3349 as a follow on
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.
Yes, I was wondering about this and follow on work for dropping schema, etc. A lot of plumbing here, and I'm not sure it works if you have your own CatalogProvider.
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.
Yes, I was wondering about this and follow on work for dropping schema, etc. A lot of plumbing here, and I'm not sure it works if you have your own CatalogProvider.
I agree -- it does not work if you have your own CatalogProvider without some more work. I this behavior is fine, as long as the point is clear to users.
let plan = LogicalPlanBuilder::empty(false).build()?; | ||
Ok(Arc::new(DataFrame::new(self.state.clone(), &plan))) | ||
} | ||
(true, false, Ok(_)) => self.return_empty_dataframe(), |
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 change to refactor and reduce duplicated code, is a very nice example of leaving the code better than when you found it. It is very much appreciated @kmitchener
|
||
#[tokio::test] | ||
#[should_panic(expected = "doesn't exist")] | ||
async fn drop_view_cant_drop_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.
👍 nice
Benchmark runs are scheduled for baseline = 0fc7297 and contender = 5621e3b. 5621e3b is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
Which issue does this PR close?
Closes #3251.
Rationale for this change
What changes are included in this PR?
drop view
anddrop view if exists
drop table
so it only works on tables, not viewsdrop view
Are there any user-facing changes?