Skip to content
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

fix: EXPOSED-122 Fix timestampWithTimeZone tests in Oracle #1829

Merged
merged 1 commit into from
Aug 10, 2023

Conversation

bog-walk
Copy link
Member

@bog-walk bog-walk commented Aug 9, 2023

The following test fails when run on Oracle in the 3 modules: exposed-kotlin-datetime, exposed-java-time, exposed-jodatime

DefaultsTest/testTimestampWithTimeZoneDefaults()

The following tests also fail when run on Oracle, but in exposed-jodatime only:

JodaTimeBaseTest/testTimestampWithTimeZone()
JodaTimeMiscTableTest/testTimestampWithTimeZone()

Issue 1:

Fails with: ORA-01861: literal does not match format string
Because Oracle is set to use the default formatter, instead of the accepted pattern:

Current -> TIMESTAMP '2023-08-09T11:26:32.7367231Z'
Accepted -> TIMESTAMP '2023-08-09 11:26:32.7367231 +00:00'

Oracle now has its own datetime formatter in each module.

Issue 2:

In exposed-jodatime module only, reading a timestamp with time zone object in Oracle then fails with a NPE at this line: rs.getObject(index, offsetDateTimeClass).
This occurs because of a read conversion error since DateTime is sent to the DB as java.sql.Timestamp and ends up being stored as oracle.sql.TIMESTAMPTZ.

The object is instead read and retrieved as a java.sql.Timestamp.

The following test fails when run on Oracle in the 3 modules:
exposed-kotlin-datetime, exposed-java-time, exposed-jodatime

DefaultsTest/testTimestampWithTimeZoneDefaults

The following tests fail when run on Oracle in exposed-jodatime only:

JodaTimeBaseTest/testTimestampWithTimeZone
JodaTimeMiscTableTest/testTimestampWithTimeZone

Issue 1:
Fails with:
ORA-01861: literal does not match format string
Because Oracle is set to use the default formatter (2023-08-09T11:26:32.7367231Z)
instead of the expected pattern (2023-08-09 11:26:32.7367231 +00:00).

Oracle now has its own datetime formatter in each module.

Issue 2:

In exposed-jodatime module only, reading a timestamp with time zone object in Oracle
then fails with a NPE. This occurs because of a read conversion error since DateTime
is sent to the DB as java.sql.Timestamp and ends up being stored as oracle.sql.TIMESTAMPTZ.

The object is instead read and retrieved as a java.sql.Timestamp.
@bog-walk bog-walk requested review from e5l and joc-a August 9, 2023 19:36
Copy link
Member

@e5l e5l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@bog-walk bog-walk merged commit d168bd4 into main Aug 10, 2023
3 checks passed
@bog-walk bog-walk deleted the bog-walk/fix-oracle-tz-tests branch August 10, 2023 12:09
saral pushed a commit to saral/Exposed that referenced this pull request Oct 3, 2023
…#1829)

The following test fails when run on Oracle in the 3 modules:
exposed-kotlin-datetime, exposed-java-time, exposed-jodatime

DefaultsTest/testTimestampWithTimeZoneDefaults

The following tests fail when run on Oracle in exposed-jodatime only:

JodaTimeBaseTest/testTimestampWithTimeZone
JodaTimeMiscTableTest/testTimestampWithTimeZone

Issue 1:
Fails with:
ORA-01861: literal does not match format string
Because Oracle is set to use the default formatter (2023-08-09T11:26:32.7367231Z)
instead of the expected pattern (2023-08-09 11:26:32.7367231 +00:00).

Oracle now has its own datetime formatter in each module.

Issue 2:

In exposed-jodatime module only, reading a timestamp with time zone object in Oracle
then fails with a NPE. This occurs because of a read conversion error since DateTime
is sent to the DB as java.sql.Timestamp and ends up being stored as oracle.sql.TIMESTAMPTZ.

The object is instead read and retrieved as a java.sql.Timestamp.
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