Repository navigation
fix(jdbc): drop duplicate checkClosed in prepared execute - #150
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 #81
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 and conformance foundation, never a copy target.What changed
LibsqlPreparedStatement.executeCurrent()calledcheckClosed(); beginExecution(); checkClosed();. The second check runs after the state transition and beforeconnection.executeStatement, which already checks the connection itself. Removed it, leaving the singlecheckClosed()before the state transition.One file changed, one line deleted, no behavior change.
Divergence from the plan's Files block
LibsqlStatement.javais in the plan's Files block but needed no edit: its secondcheckClosed()was already removed in4b30b46(#85), which matched xerial's tolerance ofexecuteafterstatement.close(). That behavior is pinned byLibsqlStatementLifecycleTest.executeAndGetConnectionStillWorkAfterClose(#148), so adding acheckClosed()to the statement execute path would be a behavior change and was not done.executeSqlreadsbeginExecution();with the connection check insideLibsqlConnection.executeStatement.Evidence
Red at trunk (
origin/mainde31dc6):executeCurrentat lines 231-235 readscheckClosed(); beginExecution(); checkClosed();. Green at head (2621b71): one check. Log:/tmp/xerial-parity-i81/lane-3-specific.log.Lanes at head (logs under
/tmp/xerial-parity-i81/):LibsqlStatementLifecycleTest+ 6LibsqlPreparedStatementTest= 27/27 pass on both sides (trunk-unit.log,head-unit.log).lane-3-specific.log).-pl libsql-jdbc test: BUILD SUCCESS, 293/293 (lane-4-module-suite.log); trunk is also 293/293 (trunk-module-suite.log).-pl libsql-conformance -am verify: BUILD SUCCESS, 123 tests, 0 failures, 1 skipped, no divergence line (lane-5-conformance.log).-Pxerial-control verify: BUILD SUCCESS, 100 tests, 0 failures, 1 skipped; differences are the pre-existing reference notes, none introduced here (lane-6-control.log).spotless:check: BUILD SUCCESS (lane-7-spotless.log)../mvnw test: BUILD SUCCESS, 293/293 inlibsql-jdbc(lane-8-reactor.log).lane-9-specific.log).-pl libsql-jdbc -am package -DskipTests: BUILD SUCCESS, driver jar built (lane-10-package.log).Perf: three interleaved
./mvnw -pl libsql-jdbc test -qruns per side, trunk first. Trunk median 2.161 s, head median 2.167 s (+0.3%, within the 10% rule). Raw values inperf-raw.txt.Base
de31dc6, head2621b71e5c77c5a9976519942e2b8d5b2044ff29.No merge; stopping at merge-ready.