Repository navigation
fix(jdbc): map in-transaction Hrana errors through the error mapper - #149
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.
Fixes #109
Contract: Hrana 3 is the source of truth for transport, values, metadata, batching, transactions, and error reporting.
java.sqlis the source of truth for the JDBC surface. xerial/sqlite-jdbc is a behavioral reference, never a copy target.Inside a transaction, a
StreamResult.Errorwas turned into a plainSQLException(message), so SQLState, vendor code, and the constraint category were lost. All four result sites now throwLibsqlErrorMapper.toSQLException(HranaError):executeStatement,beginTransaction,endTransaction, andextractBatchResults.BatchUpdateExceptionnow carries the mapped SQLState/vendor code and keeps the mapped exception as its cause.Error.codeis mapped when present. Because Hrana 3 says the codes are not yet stabilized, an unrecognized or absent code falls back to categorizing the SQLite message (UNIQUE constraint failed,FOREIGN KEY constraint failed,NOT NULL constraint failed,CHECK constraint failed), so a unique violation maps toSQLIntegrityConstraintViolationException/23000even when sqld sends no code.Base:
c3ef4de03b4188dfb98cc3e8d565b12ea41bec1bHead:
2612b9e10a4ae23b673c9ef56e102e5d0ad3410dRed: with the new
LibsqlConnectionTestcases applied to trunk, 7 fail: the two transaction-mode halves of the unique-violation case and every explicit begin/execute/end/batch case; the auto-commit half passes on trunk (it already used the mapper). Log:/tmp/xerial-parity-i109/lane-1-regression.log.Green: 36/36
LibsqlConnectionTestcases pass at the head (/tmp/xerial-parity-i109/green-unit.log).Lanes (all at head
2612b9e, logs in/tmp/xerial-parity-i109/):BatchUpdateExceptionwraps the mapped cause../mvnw -pl libsql-jdbc test— 293 pass, BUILD SUCCESS.spotless:check— BUILD SUCCESS.TransactionLifecycleIT#uniqueViolationKeepsItsMappedSqlStateInBothModes) — pass; real sqld error keeps23000in both modes.Perf: three interleaved
time ./mvnw -pl libsql-jdbc testruns per side, repeated once (six samples each). Trunk median 2.108 s, head median 2.111 s (+0.1%), within the 10% rule.Files outside the plan's Files block:
LibsqlErrorMapper.java: required to add theHranaErroroverload and keep one mapping path, as the issue asks.libsql-itests/.../TransactionLifecycleIT.java: lane 9 asks for a transaction-error itest; no existing case asserted SQLState against real sqld.No other divergences.