Skip to content

[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

Closed
wants to merge 3 commits into from

Conversation

gatorsmile
Copy link
Member

@gatorsmile gatorsmile commented May 2, 2017

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.

java.sql.SQLException: Unsupported type 2014

After this PR, the message is like

java.sql.SQLException: Unsupported type TIMESTAMP_WITH_TIMEZONE
  • Also upgrade the H2 version to 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.

@SparkQA
Copy link

SparkQA commented May 2, 2017

Test build #76393 has finished for PR 17835 at commit d199f7b.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@@ -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)
Copy link
Member

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?

Copy link
Member Author

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!

Copy link
Member

@dongjoon-hyun dongjoon-hyun May 6, 2017

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.

Copy link
Member

@dongjoon-hyun dongjoon-hyun May 6, 2017

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.

@SparkQA
Copy link

SparkQA commented May 6, 2017

Test build #76512 has started for PR 17835 at commit 134d6e9.

@gatorsmile
Copy link
Member Author

retest this please

@gatorsmile gatorsmile changed the title [SPARK-20557] [SQL] Improve the error message for unsupported JDBC types. [SPARK-20557] [SQL] Support JDBC data type Time with Time Zone May 6, 2017
@dongjoon-hyun
Copy link
Member

+1 LGTM.

@SparkQA
Copy link

SparkQA commented May 6, 2017

Test build #76519 has finished for PR 17835 at commit 134d6e9.

  • This patch fails PySpark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@gatorsmile
Copy link
Member Author

retest this please

@SparkQA
Copy link

SparkQA commented May 6, 2017

Test build #76526 has finished for PR 17835 at commit 134d6e9.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@gatorsmile
Copy link
Member Author

Thanks! Merging to master.

@asfgit asfgit closed this in cafca54 May 7, 2017
ghost pushed a commit to dbtsai/spark that referenced this pull request Dec 12, 2017
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants