Find the framework surface we do not implement, and write it down

[ShawnChen-Sirius]

Refs #11. Does not close it — Spring JdbcTemplate is still open, and ShardingSphere turns out
not to be closable here at all.

The issue said the deliverable is less the passing test than the list of unconditionally-called
surface we do not implement. Here is that list, and the headline is that it is empty.

DatabaseMetaData, the DBeaver stand-in

DatabaseMetaDataSurfaceIT invokes all 179 methods of JDBC 4.3's DatabaseMetaData
reflectively, with the arguments a GUI would pass:

Outcome	Count
Returned a value or a result set with rows	160
Returned an empty result set	19
Threw SQLFeatureNotSupportedException	0
Threw anything else	0

So the risk the issue names — "a SQLFeatureNotSupportedException thrown from somewhere DBeaver
calls unconditionally would make the driver look broken on first contact" — does not exist.

The test does not stop at non-null. Every metadata result set is checked against the JDBC 4.3
column labels transcribed from the specification, not read back from the driver, and every
ResultSetMetaData accessor is called on every column of every one. All present, all answerable,
rows or not. That is the empty-ResultSet-with-correct-metadata path the issue flagged as a
different code path, and it is correct.

The 19 empty ones: getAttributes, getBestRowIdentifier, getCatalogs,
getClientInfoProperties, getColumnPrivileges, getCrossReference, getExportedKeys,
getFunctionColumns, getImportedKeys, getIndexInfo, getPrimaryKeys, getProcedureColumns,
getProcedures, getPseudoColumns, getSuperTables, getSuperTypes, getTablePrivileges,
getUDTs, getVersionColumns.

Per framework

• MyBatis 3.5.19 — works, 8 tests. Finding: the default JdbcTransactionFactory with
  openSession() calls setAutoCommit(false), which the driver refuses; use openSession(true)
  or ManagedTransactionFactory. Auto-mapping picks the right TypeHandler per column and
  insert() returns the real affected-row count.
• jOOQ 3.16.23 — works, 8 tests, two findings: .limit() fails by default because it is
  rendered as a bind value (fix: StatementType.STATIC_STATEMENT), and transaction() is refused
  with no setting to avoid it. Also recorded so it is not mistaken for a driver bug: jOOQ types
  every chDB column as Object because SQLDialect.DEFAULT has no Int32/DateTime64. The
  driver reports INTEGER/Int32/java.lang.Integer correctly on populated and zero-row sets,
  which is asserted.
• ShardingSphere 5.5.3 — cannot be wired up, and it is upstream's doing. It already lists
  jdbc:chdb among its ClickHouse URL prefixes, but every DatabaseType then parses the URL with
  StandardJdbcUrlParser, which requires the //authority of a client/server URL. jdbc:chdb:,
  jdbc:chdb::memory: and a filesystem storage path all fail with
  UnrecognizedDatabaseURLException; the YAML driver and ShardingSphereDataSourceFactory fail
  identically, so no configuration reaches the driver. ShardingSphereIT pins this with 3 tests so
  it flips when upstream changes. Its connection management versus one-storage-path-per-JVM
  therefore stays untested; HikariPoolIT is the nearest cover, since ShardingSphere's own pools
  are HikariCP.
• DBeaver — no blocker found, via the sweep above.

A cross-cutting finding

Bound parameters are typed String, because the engine's binding is textual. Measured on 26.7.0:
fine in = ? < ? > ? IN (?) and string contexts; fails in LIMIT ? / OFFSET ? (Code 440),
in arithmetic (Code 43), and in numeric table-function arguments like numbers(?) (Code 43). This
is the root cause of the jOOQ .limit() failure. Workaround is to cast in SQL — toUInt64(?).
Recorded in docs/unsupported.md; it deserves its own issue.

Nothing here is blocked on #12

The driver's DatabaseMetaData is implemented as plain SELECTs against system.* tables, so
none of the metadata surface touches SHOW or DESCRIBE.

Also in this PR

Three status lines that described the state before HikariPoolIT landed — the README row, the
phase-9 row in docs/v1-progress.md, and the docs/release-readiness.md gap table. The last was
the misleading one: it grouped ShardingSphere with Spring as "lower yield, half a day", when
ShardingSphere is not lower yield but unreachable.

Verified

mvn -pl chdb-jdbc,chdb-integration-tests -am verify on macos-aarch64: 148 unit + 127 integration
tests, 0 failures. mvn -pl chdb-jdbc dependency:tree shows exactly one dependency,
junit-jupiter:test — the driver's zero-third-party-runtime-dependency property is intact. New
dependencies are test scope only, with the version choices justified in the pom against the Java 11
floor (jOOQ 3.17.0 is class file 61, read out of the published jar).

🤖 Generated with Claude Code

Note

Add integration tests for DatabaseMetaData surface, jOOQ, MyBatis, and ShardingSphere

• Adds DatabaseMetaDataSurfaceIT.java which reflectively invokes every DatabaseMetaData method from the running JDK, classifies outcomes, and verifies every ResultSet-returning method exposes the expected JDBC column labels
• Adds JooqIT.java covering jOOQ 3.16 dialect selection, metadata walks, bind-value limits, type inference gaps, and transaction behavior
• Adds MyBatisIT.java covering automatic mapping, #{...} parameter binding, type-handler selection, and transaction factories
• Adds ShardingSphereIT.java showing that ShardingSphere recognizes jdbc:chdb as a ClickHouse prefix but rejects embedded URL forms lacking an authority
• Updates docs/unsupported.md, docs/v1-progress.md, and README.md to record the tested framework surface, the ShardingSphere URL-parser blocker, and the string-bound-parameter limitation

^{Macroscope summarized a312ae9.}