-
Notifications
You must be signed in to change notification settings - Fork 611
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
feat(api): make create_table uniform #5736
Conversation
a07a119
to
969e26b
Compare
Thoughts on forcing keyword arguments for a bunch of these DDL functions? |
SGTM |
00f2e31
to
d4e9e9b
Compare
21ce5af
to
cc54ea2
Compare
cc54ea2
to
0280bef
Compare
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 good to me -- I'll leave it for a bit in case anyone else wants to take a reviewing pass.
There are some snowflake things that are failing locally for me. #5741 should help with that |
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.
Overall looks good to me. A few small questions/comment, but none should be blockers.
a20b677
to
455c1a5
Compare
455c1a5
to
43099cb
Compare
43099cb
to
46c1330
Compare
bc60aee
to
b6f5df7
Compare
Cloud backends:
|
571b466
to
ada0f20
Compare
I am authoring a longer commit message, hold off on merging please! |
ada0f20
to
c433691
Compare
This commit addresses most outstanding DDL API discrepancy issues including: - `create_table`/`create_view` for pandas, dask and polars - making the various DDL APIs as uniform as possible (see clickhouse for an example of divergence) - deprecation of `load_data` (except on impala, since it's significantly different from the others) - add clickhouse implementations of `create_table`/`create_view`/`create_database` - standardization of APIs for creating tables During the process of getting all of this to work, I uncovered multiple issues with `snowflake-sqlalchemy`'s quoting behavior and had to monkey patch in `normalize_name` to avoid the broken heuristic they are using. Additionally, to avoid having to solve the "which case should I use?" problem in multiple places, I decided to remove our backend-scoped use of `sqlalchemy.MetaData`. Without removing it, we'd have to deal with identifiers' case not matching. It's possible there's a performance hit, but removing this maintenance burden until someone comes along saying it's slow is worth it IMO. BREAKING CHANGE: Snowflake identifiers are now kept **as is** from the database. Many table names and column names may now be in SHOUTING CASE. Adjust code accordingly.
c433691
to
dbfe647
Compare
Ok, merging on green! |
This PR address recent issues created around DDL.
Notes
ImpalaTable.load_data
. I'm not entirely what should be done with it.create_table
, since clickhouse itself doesn't have a defaulttable engine, I preserved that: you have to pass
engine="Something"
to itscreate_table. It breaks the uniformity, but I'm not sure how else to handle
it.
TODO
create_view
for pandas/dask/polarscreate_view
/drop_table
/truncate_table
for clickhousetruncate_table
(I don't think these makes sense for the in-memory backends, so those'll raise an exception)Closes #5394
Closes #5392
Closes #5390
Closes #4316
Closes #2339