Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#889 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python, sql

Direzione di ricerca

Inizia con il diff della PR di coverage sotto tests/, in particolare test_get_tables_empty_table_types_filter_matches_all e test_failed_statement_error_carries_sql_state, quindi traccia i corrispondenti percorsi del backend Thrift. Riproduci l’istruzione SQL relativa alla tabella inesistente e confronta Thrift con il backend del kernel. Il lavoro è completato quando entrambi i test di errore atteso passano: un table_types vuoto corrisponde a tutti i tipi e le istruzioni fallite espongono SQLSTATE 42P01 con il testo di errore previsto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
233
Fork
152
Merge medio
21h 5m
PR unite (30g)
10

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di databricks/databricks-sql-python

Tutte le issue di databricks/databricks-sql-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.