Fix client-v2: read the value when a UInt64 column is bound to a primitive POJO field - #2997
Open
polyglotAI-bot wants to merge 1 commit into
Open
Fix client-v2: read the value when a UInt64 column is bound to a primitive POJO field#2997polyglotAI-bot wants to merge 1 commit into
polyglotAI-bot wants to merge 1 commit into
Conversation
…itive POJO field The compiled POJO setter branch for a primitive field on a UInt64 column never emitted a read call, so it applied CHECKCAST BigInteger to the BinaryStreamReader itself and consumed nothing from the stream. The value is now read with readBigIntegerLE(8, true) and converted with the matching Number accessor. Fixes: #2996
|
Client V2 CoverageCoverage Report
Class Coverage
|
JDBC V2 CoverageCoverage Report
Class Coverage
|
JDBC V1 CoverageCoverage Report
Class Coverage
|
Client V1 CoverageCoverage Report
Class Coverage
|
This was referenced Aug 3, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
Fixes #2996.
SerializerUtils.compilePOJOSettergenerates the bytecode of the POJO field setter used on theread path. One branch handles a primitive target field bound to a
UInt64column, and at thatpoint the operand stack holds
[dtoObject, reader]. The branch emittedCHECKCAST BigInteger+<type>Value()without ever emitting a read call, so theCHECKCASTwas applied to theBinaryStreamReaderinstance itself — the setter always threwClassCastException: BinaryStreamReader cannot be cast to java.math.BigIntegerand consumed nothingfrom the stream. Every primitive POJO field bound to a
UInt64column was therefore unusable(boxed
BigInteger/Longfields work, because they take the genericreadValue(...)path).The branch now reads the value first —
reader.readBigIntegerLE(INT64_SIZE, true), the same read thegeneric path performs for
UInt64— and then converts it to the target primitive with the matchingNumberaccessor (longValue(),intValue(), ...), i.e. Java narrowing semantics for a value thatdoes not fit.
booleangoes through the existingSerializerUtils.convertToBoolean(Object)converter (non-zero is
true), andcharreuses the sametoPrimitiveTypemapping (char→short) the sibling primitive branch already uses, so all eight primitive types are covered.A
longholds everyUInt64value bit-for-bit (Long.toUnsignedString(long)recovers the unsigneddecimal), so nothing is lost for the natural mapping.
Changes
client-v2SerializerUtils.compilePOJOSetter: theprimitive field + UInt64 columnbranch nowdelegates to a new private
unsignedLongReaderMethodForType(...)which emits the missingreadBigIntegerLE(8, true)call before the conversion.CHANGELOG.md: bug-fix entry.DataTypeTests: regression + contrast tests (see below).Test
testReadUInt64IntoPrimitivePojoFields— readsUInt64columns intobyte,short,int,long,float,double,booleanandcharfields in one row, positioned between a leadingrowId Int32and a trailingInt64column, and asserts the whole row, so a wrong or missing readshifts the trailing column and is detected. Two rows cover
booleanfalseandtrue. It alsoasserts that the maximum
UInt64value round-trips bit-for-bit into along(
Long.toUnsignedString(...) == "18446744073709551615"). Fails onmainwith the reportedClassCastException(on the very first primitive field), passes with the fix.testReadUInt64IntoBoxedPojoField— contrast case: a boxedBigIntegerfield on the sameUInt64column still returns the exact
BigInteger, proving the untouched generic path is unchanged.DataTypeTests96/96,QueryTests96/96 (POJO read path),client-v2 -amunit suites allgreen — no existing test modified.
Pre-PR validation gate
ClassCastExceptiononmain, every run)CHECKCASTapplied to the reader)AGENTS.md/docs/ai-review.md/docs/changes_checklist.md("conditional logic or guard changed" + "null handling"/serialization sections): no public API,
config key, default or output format changes; the only behavior change is that a previously
always-throwing path now works
docs/features.mdcross-checked — POJO materialization is already listed as supportedbehavior and no listed feature changes, so no doc update is needed (this restores intended
behavior rather than adding a feature)
Note for the maintainer
This touches the same
if/elsechain as the still-open #2994 (missingNullablenull-marker readfor primitive POJO fields). They are independent fixes and compose: #2994 adds a marker-consuming
prologue to the branch, this PR fixes what the branch does afterwards. Whichever merges second will
have a trivial textual conflict in that branch; the correct resolution keeps #2994's
nullMarkerReaderForPrimitive(mv, targetType);line followed by this PR'sunsignedLongReaderMethodForType(mv, targetPrimitiveType);(readBigIntegerLEdoes not consume anull marker, so it is read exactly once). Happy to rebase whichever way you prefer.