[coverage] Conformance findings: METADATA-035,STATEMENT-023

Open
#889 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python, sql

Research direction

Start with the coverage PR diff under tests/, especially test_get_tables_empty_table_types_filter_matches_all and test_failed_statement_error_carries_sql_state, then trace the corresponding Thrift backend paths. Reproduce the nonexistent-table SQL statement and compare Thrift with the kernel backend. Done means both expected-failure tests pass: empty table_types matches all types and failed statements expose SQLSTATE 42P01 with the expected error wording.

Written by the indexing model from the issue text.

Description

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. 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-python) is fixed, then flips green as a tripwire.

Findings

  • METADATA-035 [thrift]: Thrift backend forwards an empty getTables table_types list verbatim as TGetTablesReq(tableTypes=[]), so the server treats it as match-none and returns zero rows instead of behaving like None (match all types); the kernel backend correctly normalises [] to None
    • failing test: test_get_tables_empty_table_types_filter_matches_all (see the coverage PR diff under tests/)
  • STATEMENT-023 [thrift]: Thrift backend drops the server SQLSTATE on a FAILED statement: it builds exceptions from errorMessage/displayMessage only and never copies TStatus.sqlState / TGetOperationStatusResp.sqlState, so no PEP 249 error attribute carries 42P01 for TABLE_OR_VIEW_NOT_FOUND; the kernel backend does forward sql_state
    • failing test: test_failed_statement_error_carries_sql_state (see the coverage PR diff under tests/)

Reproduce & Expected

STATEMENT-023 — Validates that when the server resolves a statement to a FAILED state, the driver surfaces the server's SQLSTATE on the raised error — not just a free-text message. A statement whose SQLSTATE is stable and server-assigned is used: a reference to a table that does not exist, which Databricks reports as TABLE_OR_VIEW_NOT_FOUND with SQLSTATE 42P01. The raised error must expose that SQLSTATE through the driver's standard error surface (ADBC AdbcException.SqlState, JDBC SQLException.getSQLState(), DBAPI error attributes, ODBC SQLGetDiagRec SQLSTATE, etc.). This pins the portable half of the cross-protocol error contract: consumers branch on the status/SQLSTATE pair, so both protocols must populate it identically even though each raises its own natural concrete exception class. The CONCRETE exception TYPE is deliberately NOT asserted — it legitimately differs per protocol and per driver (the reference driver raises DatabricksException on SEA and HiveServer2Exception on Thrift), so requiring one class would encode a driver-internal detail rather than the contract.

Reproduce:

SELECT * FROM nonexistent_catalog_xyz123.nonexistent_schema.nonexistent_table

Expected (per the shared spec):

  • full assertion contract:
result:
- error:
    sql_state: 42P01
- error:
    contains:
    - TABLE_OR_VIEW_NOT_FOUND
    - not found
    - cannot be found

Context

Dominant language
Python
Stars
233
Forks
152
Avg merge
21h 5m
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/databricks-sql-python

All issues in databricks/databricks-sql-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.