Repository navigation
refactor(jdbc): extract result-set value reads - #277
Merged
Merged
Conversation
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
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.
What changed
Moved the read-side Hrana value conversion out of
LibsqlResultSetinto a new package-privateJdbcValueReader, the counterpart of the existingJdbcValueConverter.LibsqlResultSetnow reads as navigation, column resolution, and the JDBC surface.JdbcValueReaderowns the conversion of one stored value to the Java value a getter returns.The
getObject(int, Class)conversion body moved with it. The public override still owns the null-type check, the declared-type rejection, and the JDBC contract javadoc.Behavior preserved
Every exception type and message is unchanged. Every getter returns the same value for the same storage class and declared type. The
getObjectfast path and the type if-chains moved byte for byte. The public API is unchanged.Pins added
declaredNumericTextRejectsANonNumberWithTheXerialMessageBad value for type numeric: abc.declaredNumericBlobRejectsANonNumberWithTheXerialMessagedeclaredTinyIntRejectsAValueOutsideTheIntRangegetObjectkeepsValue N does not fit the declared TINYINT type.bigDecimalRejectsNonNumericTextgetBigDecimalkeepsBad value for type BigDecimal: abc.urlRejectsMalformedTextgetURLkeepsBad value for type URL: not a url.offsetTimeRejectsMalformedTextgetObject(OffsetTime.class)keepsBad value for type OffsetTime: abc.offsetDateTimeAcceptsTheSqliteSpaceSeparatorTbefore parsing.typedIntegerTargetOnTextStorageUsesTheTargetTypeMessagegetObject(Integer.class)on TEXT keepsBad value for type Integer.Mutant kills
numerictonumber.getObjectnumeric gate to always true.Diff (file statistics)
Line counts
LibsqlResultSet.javaJdbcValueReader.javaProbe
The first probe changed the strict numeric parse message in the moved code. Two pins failed, and the message was restored. The second probe removed the storage-class gate in
getObject, and the new typed-target pin failed. Both probes left no change.Lanes
mise exec -- ./mvnw -pl libsql-jdbc -am testmise exec -- ./mvnw spotless:checkmise exec -- ./mvnw -pl libsql-conformance -am verifyDOCKER_CONFIG=... mise exec -- ./mvnw -pl libsql-itests -am verify./mvnw spotless:check)../mvnw clean verify).Closes #276