Repository navigation
fix(jdbc): stop caching a failed product-version lookup - #133
Merged
Merged
Conversation
Surface the SQLException instead of caching the 3.0 fallback, retry on the next call, and throw on a closed connection even when a version is already cached. Fixes #112.
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.
Summary
resolveDatabaseProductVersionno longer swallows a failedSELECT sqlite_version(). The"3.0"fallback is gone, the failure surfaces as aSQLException, and the next call retries. A closed connection now throws instead of returning a version, including when a version is already cached.Fixes #112
Contract
Hrana 3 governs
select sqlite_version()throughexecute;java.sqlgovernsDatabaseMetaData; xerial/sqlite-jdbc is a behavioral reference only.Change
resolveDatabaseProductVersioncallsconnection.checkClosed()before returning a cached value, so a closed connection throws even after a successful lookup.catch (SQLException)that wrote"3.0"intocachedDatabaseProductVersionis removed. Only a real version from the server is cached.SQLException("SELECT sqlite_version() returned no row")instead of falling back to"3.0".Divergences
"3.0".sqlite_version()always returns one row, so an empty result is a broken server response, not a legitimate default. Keeping the fallback, cached or not, would reintroduce the lie this issue reports.cachedDatabaseProductVersionstays unsynchronized. Two concurrent first calls can each run the lookup; the last write wins and both values are real versions, so no fallback can be pinned. This is recorded for LibsqlConnection state is not synchronized #105, which owns connection-level concurrency.Evidence
Red at trunk
4725e83, tests only, fix not applied (/tmp/xerial-parity-i112/lane-1-regression.log):Tests run: 27, Failures: 2— both new cases fail with "Expecting code to raise a throwable."Green at head
c924c4b4c7bb:LibsqlDatabaseMetaDataTest):Tests run: 27, Failures: 0, Errors: 0. The failed lookup throws, the retry returns3.45.1.3,45).-pl libsql-jdbc test):Tests run: 235, Failures: 0, Errors: 0, BUILD SUCCESS.-pl libsql-conformance -am verify):Tests run: 115, Failures: 0, Errors: 0, Skipped: 1, BUILD SUCCESS, no new divergence.-Pxerial-control verify):Tests run: 100, Failures: 0, Errors: 0, Skipped: 1, BUILD SUCCESS; no new reference difference.spotless:check): BUILD SUCCESS../mvnw test): BUILD SUCCESS.-pl libsql-jdbc -am package -DskipTests): jar built.Lane 9: the diff keeps
cachedDatabaseProductVersionunsynchronized; the #105 note above is the handoff.Files touched:
libsql-jdbc/src/main/java/com/github/magnusp/libsql/jdbc/LibsqlDatabaseMetaData.java,libsql-jdbc/src/test/java/com/github/magnusp/libsql/jdbc/LibsqlDatabaseMetaDataTest.java.Base
4725e83· Headc924c4b4c7bb.