-
Notifications
You must be signed in to change notification settings - Fork 28.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
[SPARK-32405][SQL] Apply table options while creating tables in JDBC Table Catalog #30154
Conversation
Kubernetes integration test starting |
Kubernetes integration test starting |
Kubernetes integration test status success |
Kubernetes integration test status success |
Test build #130302 has finished for PR 30154 at commit
|
retest this please |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130306 has finished for PR 30154 at commit
|
@@ -123,8 +123,14 @@ class JDBCTableCatalog extends TableCatalog with Logging { | |||
"ignored: " + properties.asScala.map { case (k, v) => s"$k=$v" }.mkString("[", ", ", "]")) |
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.
I haven't removed the Warning yet. The properties
here could be provider
, owner
, location
, comment
or TBLPROPERTIES
key value pairs. I only implemented comment
. Seems to me these are not options in standard database CREATE TABLE syntax. I am not sure if we need to support all of them.
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.
I think a more reasonable behavior is to fail if unsupported table properties are given. JDBC V2 is new in this release so we still have a chance to change it.
For these 4 builtin properties, I think we only need to support comment
. We should ignore provider
for now. And after the CRETE TABLE unification, we can force users to not specify USING
when creating table in JDBC v2.
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.
OK, so we will support comment
and ignore provider
, owner
, and location
for now.
For supported table properties, do we need to make them database specific? for example, ENGINE
and CHARSET
are supported table properties for MySQL but not supported by other databases.
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.
Instead of having a complete list of supported table properties for each of the databases, it might be better to send whatever table properties without checking and let it fail at database side if unsupported.
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.
yea, that sounds better, although it needs more work to update every dialect.
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/jdbc/JdbcUtils.scala
Show resolved
Hide resolved
We also need to retrieve the table comment in |
So we will retrieve table comment using a query and then set this comment in |
ah, it's so complicated. Let's forget about it for this PR. |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130480 has finished for PR 30154 at commit
|
retest this please |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130485 has finished for PR 30154 at commit
|
...ore/src/main/scala/org/apache/spark/sql/execution/datasources/v2/jdbc/JDBCTableCatalog.scala
Show resolved
Hide resolved
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/jdbc/JdbcUtils.scala
Show resolved
Hide resolved
e267481
to
d4b1cf9
Compare
Kubernetes integration test starting |
Kubernetes integration test starting |
Kubernetes integration test status failure |
Kubernetes integration test status success |
external/docker-integration-tests/src/test/scala/org/apache/spark/sql/jdbc/v2/V2JDBCTest.scala
Show resolved
Hide resolved
Test build #130640 has finished for PR 30154 at commit
|
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130670 has finished for PR 30154 at commit
|
case "provider" => | ||
case "owner" => // owner is ignored. It is default to current user name. | ||
case "location" => | ||
throw new AnalysisException("Cannot create JDBC table with property location.") |
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.
let's be more user-facing: CREATE TABLE ... LOCATION ... is not supported in the JDBC catalog.
39057aa
to
ecc9a4e
Compare
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130696 has finished for PR 30154 at commit
|
retest this please |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #130731 has finished for PR 30154 at commit
|
thanks, merging to master! |
Thank you! @cloud-fan |
What changes were proposed in this pull request?
Currently in JDBCTableCatalog, we ignore the table options when creating table.
Why are the changes needed?
need to apply the table options when we create table
Does this PR introduce any user-facing change?
no
How was this patch tested?
add new test