Summary
Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-nodejs) is fixed, then flips green as a tripwire.
Findings
- TRANSACTION-021 [thrift]: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on thrift: the driver keeps no capability info table and forwards isolation info codes to the server, which does not answer them, so it advertises no transaction-isolation support while Delta runs serializable-class transactions (same under-reporting class as databricks-odbc#137)
- failing test:
TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail] (see the coverage PR diff under tests/)
- TRANSACTION-021 [sea]: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on the SEA kernel path too: no driver-side capability info table, so the isolation codes are forwarded to a server that answers only CLI_SERVER_NAME/CLI_DBMS_NAME/CLI_DBMS_VER, leaving isolation capability unadvertised
- failing test:
TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail] (see the coverage PR diff under tests/)
- TRANSACTION-021: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on thrift and sea: the driver keeps no capability info table and forwards isolation info codes to the server, which does not answer them, so it advertises no transaction-isolation support while Delta runs serializable-class transactions (same under-reporting class as databricks-odbc#137)
Reproduce & Expected
TRANSACTION-021 — Verify the driver's ISOLATION METADATA truthfully advertises the level it actually supports, and agrees with the connection attribute asserted by TRANSACTION-013/014.
Reproduce:
- Read the driver's DEFAULT isolation level from its metadata surface (ODBC:
SQLGetInfo(SQL_DEFAULT_TXN_ISOLATION); JDBC:
DatabaseMetaData.getDefaultTransactionIsolation(); Node.js:
session.getInfo(CLI_DEFAULT_TXN_ISOLATION)).
- Read the SUPPORTED-levels capability (ODBC: SQLGetInfo(SQL_TXN_ISOLATION_OPTION) mask;
JDBC: supportsTransactionIsolationLevel(level) probed per level).
Context
Summary
Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-nodejs) is fixed, then flips green as a tripwire.
Findings
TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail](see the coverage PR diff undertests/)TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail](see the coverage PR diff undertests/)Reproduce & Expected
TRANSACTION-021 — Verify the driver's ISOLATION METADATA truthfully advertises the level it actually supports, and agrees with the connection attribute asserted by TRANSACTION-013/014.
Reproduce:
SQLGetInfo(SQL_DEFAULT_TXN_ISOLATION); JDBC:
DatabaseMetaData.getDefaultTransactionIsolation(); Node.js:
session.getInfo(CLI_DEFAULT_TXN_ISOLATION)).
JDBC: supportsTransactionIsolationLevel(level) probed per level).
Context