fix!: EXPOSED-360 Storing ULong.MAX_VALUE in ulong column not working #2068
+49
−23
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
force-pushed
the
joc/exposed-360
branch
3 times, most recently
from
0742540
to
00a0cfb
Compare
joc-a
force-pushed
the
joc/exposed-360
branch
3 times, most recently
from
d246ec4
to
942c654
Compare
joc-a
changed the title
joc-a
changed the title
joc-a
force-pushed
the
joc/exposed-360
branch
2 times, most recently
from
74a7416
to
fc50ff2
Compare
Before this fix, the maximum value that could be stored with `ULongColumnType` for all database dialects was `Long.MAX_VALUE`. This is because the `ULong` value was being converted to `Long` in the `notNullValueToDB` function, restricting the range to that of `Long`. Instead, it is now converted to a `Long` only for PostgreSQL, and a `String` for the rest of the database dialects. For PostgreSQL, it is not possible to store a value greater than `Long.MAX_VALUE` at the moment. This is because it's not possible to have an auto-increment column of the same type NUMERIC(20), and having different types for `ulongType()` and `ulongAutoincType()` will cause a crash when one references the other. This will be solved in another pull request. Breaking change: `ulongType()` is now NUMERIC(20) instead of BIGINT for H2, SQL Server, and SQLite, to allow storing the full range of `ULong`.
joc-a
changed the title
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 issue:
When attempting to store
ULong.MAX_VALUEin aulongcolumn, retrieving it results in -1 and notULong.MAX_VALUEfor all database dialects (except for MySQL and MariaDB). The reason is that we invoke.toLong()on theULongvalue before we store it in the database (innotNullValueToDBinULongColumnType) and that gets the -1 from here because of the implementation ofULong.toLong().The fix:
Before this fix, the maximum value that could be stored with
ULongColumnTypefor all database dialects (except for MySQL and MariaDB) wasLong.MAX_VALUE. This is because theULongvalue was being converted toLongin thenotNullValueToDBfunction, restricting the range to that ofLong. Instead, it is now converted to aBigIntegerfor PostgreSQL, aLongfor PostgreSQLNG (with a range check), and aStringfor the rest of the database dialects. Theulongcolumn can now storeULong.MAX_VALUEfor H2 (excluding H2_PSQL), Oracle, SQLite and SQL Server.Breaking change:
ulongType()is now NUMERIC(20) instead of BIGINT for H2 (excluding H2_PSQL), SQLite, and SQL Server to allow storing the full range ofULong, includingULong.MAX_VALUE.Limitations:
ulongType()to NUMERIC(20) because that would cause a mismatch when it references an auto-incrementing ulong column of type BIGSERIAL. It's also not possible to change theautoIncTypeto NUMERIC(20) either, because PostgreSQL does not support the AUTO_INCREMENT property. So the maximum value that can be stored isLong.MAX_VALUE.ulongauto-increment column is the same as that of alongcolumn.