Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
#889 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
冷清
技術堆疊
python, sql

研究方向

先查看 tests/ 下的 coverage PR diff,尤其是 test_get_tables_empty_table_types_filter_matches_all 和 test_failed_statement_error_carries_sql_state,接著追蹤對應的 Thrift backend 路徑。重現針對不存在資料表的 SQL 陳述式,並比較 Thrift 與 kernel backend。完成的標準是兩個預期失敗測試都通過:空的 table_types 符合所有類型,且失敗的陳述式會以預期的錯誤文字揭露 SQLSTATE 42P01。

由索引模型根據 Issue 內容生成。

描述

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

主要語言
Python
星號
233
分支
152
平均合併
21 小時 5 分鐘
30 天內合併 PR
10

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

databricks/databricks-sql-python 的其他 Issue

查看 databricks/databricks-sql-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。