-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[SPARK-20557] [SQL] Support JDBC data type Time with Time Zone #17835
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
Conversation
Test build #76393 has finished for PR 17835 at commit
|
@@ -230,7 +230,9 @@ object JdbcUtils extends Logging { | |||
// scalastyle:on | |||
} | |||
|
|||
if (answer == null) throw new SQLException("Unsupported type " + sqlType) | |||
if (answer == null) { | |||
throw new SQLException("Unsupported type " + JDBCType.valueOf(sqlType).getName) |
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.
Hi, @gatorsmile .
Then, it seems that we need to consider IllegalArgumentException
from JDBCType.valueOf
then.
Can we do that here?
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.
Captured in line 236. Thanks!
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.
Ur, I thought JDBCType.valueOf(sqlType)
might throw IllegalArgumentException
with invalid sqlType
.
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.
Oh, sorry. I saw an old code. Forget about that.
Test build #76512 has started for PR 17835 at commit |
retest this please |
+1 LGTM. |
Test build #76519 has finished for PR 17835 at commit
|
retest this please |
Test build #76526 has finished for PR 17835 at commit
|
Thanks! Merging to master. |
…ialect ## What changes were proposed in this pull request? In the previous PRs, apache#17832 and apache#17835 , we convert `TIMESTAMP WITH TIME ZONE` and `TIME WITH TIME ZONE` to `TIMESTAMP` for all the JDBC sources. However, this conversion could be risky since it does not respect our SQL configuration `spark.sql.session.timeZone`. In addition, each vendor might have different semantics for these two types. For example, Postgres simply returns `TIMESTAMP` types for `TIMESTAMP WITH TIME ZONE`. For such supports, we should do it case by case. This PR reverts the general support of `TIMESTAMP WITH TIME ZONE` and `TIME WITH TIME ZONE` for JDBC sources, except ORACLE Dialect. When supporting the ORACLE's `TIMESTAMP WITH TIME ZONE`, we only support it when the JVM default timezone is the same as the user-specified configuration `spark.sql.session.timeZone` (whose default is the JVM default timezone). Now, we still treat `TIMESTAMP WITH TIME ZONE` as `TIMESTAMP` when fetching the values via the Oracle JDBC connector, whose client converts the timestamp values with time zone to the timestamp values using the local JVM default timezone (a test case is added to `OracleIntegrationSuite.scala` in this PR for showing the behavior). Thus, to avoid any future behavior change, we will not support it if JVM default timezone is different from `spark.sql.session.timeZone` No regression because the previous two PRs were just merged to be unreleased master branch. ## How was this patch tested? Added the test cases Author: gatorsmile <gatorsmile@gmail.com> Closes apache#19939 from gatorsmile/timezoneUpdate.
What changes were proposed in this pull request?
This PR is to support JDBC data type TIME WITH TIME ZONE. It can be converted to TIMESTAMP
In addition, before this PR, for unsupported data types, we simply output the type number instead of the type name.
After this PR, the message is like
1.4.195
which has the type fix for "TIMESTAMP WITH TIMEZONE". However, it is not fully supported. Thus, we capture the exception, but we still need it to partially test the support of "TIMESTAMP WITH TIMEZONE", because Docker tests are not regularly run.How was this patch tested?
Added test cases.