test: Fix failing datetime comparison tests in Oracle #1813
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joc-a
approved these changes
Aug 1, 2023
exposed-java-time/src/test/kotlin/org/jetbrains/exposed/JavaTimeTests.kt
Outdated
Show resolved
Hide resolved
In both exposed-java-time and exposed-kotlin-datetime modules: MiscTableTest/testSelect01() MiscTableTest/testSelect02() Fails with an internal equality comparison issue due to precision. The datetime() column maps to TIMESTAMP without specifying a precision, so each DB defaults to a certain number of digits. This number is 6 in Oracle, and the value is round up internally instead of being truncated. Explicitly casting the datetime literal in the WHERE clause causes the appropriate comparison to occur. A new unit test specifically for this issue showed that the same issue was also occurring in certain H2 modes, causing flaky local tests.
Rename database list that requires casting.
bog-walk
force-pushed
the
bog-walk/fix-oracle-datetime-comparison
branch
from
3c9b19e to
834d762
Compare
saral
pushed a commit
to saral/Exposed
that referenced
this pull request
Oct 3, 2023
* test: Fix failing datetime comparison tests in Oracle In both exposed-java-time and exposed-kotlin-datetime modules: MiscTableTest/testSelect01() MiscTableTest/testSelect02() Fails with an internal equality comparison issue due to precision. The datetime() column maps to TIMESTAMP without specifying a precision, so each DB defaults to a certain number of digits. This number is 6 in Oracle, and the value is round up internally instead of being truncated. Explicitly casting the datetime literal in the WHERE clause causes the appropriate comparison to occur. A new unit test specifically for this issue showed that the same issue was also occurring in certain H2 modes, causing flaky local tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The following tests in
exposed-java-timeandexposed-kotlin-datetimefail when run using Oracle:MiscTableTest/testSelect01()
MiscTableTest/testSelect02()
Fails with an internal equality comparison issue due to precision, which returns an empty collection when
single()is called.The
datetime()column maps toTIMESTAMPwithout specifying a precision, so the DB defaults to a length of 6 digits, and the value is round up internally instead of being truncated.For example, if the value "2023-07-31 13:00:21.871130789" is inserted, the value stored is
2023-07-31T13:00:21.871131. This causes an issue in the WHERE clause when the literal comparison value'2023-07-31 13:00:21.871'is used.Explicitly casting the datetime literal in the WHERE clause causes the appropriate comparison to occur.
A new unit test specifically for this comparison issue showed that the same issue was also occurring in certain H2 modes, causing flaky local tests.