[coverage] Conformance findings: METADATA-028,METADATA-035,METADATA-036,METADATA-037,METADATA-038

Aperta
#479 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
node.js, sql, typescript
Ambito
api, backend

Direzione di ricerca

Inizia con i test di riproduzione METADATA-028, METADATA-035, METADATA-036, METADATA-037 e METADATA-038 nella PR di coverage sotto tests, quindi traccia gli entry point GetPrimaryKeys, GetTables e GetCrossReference in questo connector. Usa i risultati attesi e le asserzioni sul conteggio delle chiamate a ExecuteStatement come criteri di completamento, inclusa la differenza documentata tra Thrift e SEA.

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-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

  • METADATA-028 [sea]: SEA getPrimaryKeys with a NULL tableName dies at the napi FFI boundary ("Failed to convert JavaScript value Undefined into rust type String") instead of raising a clean invalid-argument error (SQLSTATE 42000) naming the missing table argument
    • failing test: METADATA-028 — getPrimaryKeys with NULL tableName is rejected with an argument error [sea] (see the coverage PR diff under tests/)
  • METADATA-035 [thrift, sea]: getTables with an empty tableTypes list ([]) is treated as "match none" and returns 0 rows instead of behaving like null and matching ALL table types; same match-none defect as databricks-jdbc#1570 / databricks-sql-kernel#187
    • failing test: getTables — empty tableTypes filter matches ALL table types, like null [thrift], getTables — empty tableTypes filter matches ALL table types, like null [sea] (see the coverage PR diff under tests/)
  • METADATA-036 [sea]: SEA getPrimaryKeys/getCrossReference with a catalog set and the corresponding schema NULL dies at the napi FFI boundary instead of raising the clean client-side invalid-argument error (SQLSTATE 42000) naming the schema argument
    • failing test: METADATA-036 — getPrimaryKeys and getCrossReference reject a catalog set with a NULL schema [sea] (see the coverage PR diff under tests/)
  • METADATA-037 [sea]: SEA getCrossReference with a NULL foreign table THROWS a napi FFI conversion error instead of treating the argument as unspecified and returning an empty result (Thrift correctly returns empty)
    • failing test: METADATA-037 — getCrossReference with NULL foreign table returns empty, no error [sea] (see the coverage PR diff under tests/)
  • METADATA-038 [sea]: SEA getCrossReference with BOTH parent and foreign table NULL throws a napi FFI conversion error instead of returning an empty result per the JDBC-SEA reference, so the documented Thrift-vs-SEA divergence is not honored on the SEA side
    • failing test: METADATA-038 — getCrossReference with BOTH tables NULL: Thrift rejects, SEA returns empty [sea] (see the coverage PR diff under tests/)
  • METADATA-028: SEA getPrimaryKeys with a NULL tableName dies at the napi FFI boundary ("Failed to convert JavaScript value Undefined into rust type String") instead of raising a clean invalid-argument error (SQLSTATE 42000) naming the missing table argument; Thrift rejects it correctly
  • METADATA-035: getTables with an empty tableTypes list ([]) is treated as "match none" and returns 0 rows on BOTH thrift and sea, instead of behaving like null and matching ALL table types (fixture TABLE and VIEW both missing); same match-none defect as databricks-jdbc#1570 / databricks-sql-kernel#187
  • METADATA-036: SEA getPrimaryKeys/getCrossReference with a catalog set and the corresponding schema NULL dies at the napi FFI boundary ("Failed to convert JavaScript value Undefined into rust type String") instead of raising the clean client-side invalid-argument error (SQLSTATE 42000) naming the schema argument
  • METADATA-038: SEA getCrossReference with BOTH parent and foreign table NULL throws a napi FFI conversion error instead of returning an empty result per the JDBC-SEA reference behavior, so the documented Thrift-vs-SEA divergence is not honored on the SEA side

Reproduce & Expected

METADATA-028 — Validates GetPrimaryKeys rejects a NULL/empty table name with a clear argument error.

Reproduce:

  • Call GetPrimaryKeys with catalog and schema set but NO table name

Expected (per the shared spec):

  • [sea] exactly 0 ExecuteStatement call(s)
  • full assertion contract:
result:
- error:
    contains:
    - table
    - 'null'
- sql_state: '42000'
protocol:
  sea:
  - call_count:
      operation: ExecuteStatement
      expected: 0
METADATA-035 — Validates that GetTables treats an EMPTY table-types filter (types: []) the same as a null filter (match ALL table types), rather than matching nothing.

Reproduce:

  • Call GetObjects with tableTypes = [] (empty, non-null list)

Expected (per the shared spec):

  • GetObjects completes successfully with an empty table-types filter
  • The TABLE is returned (empty filter matched it). Assert.Contains(tables, t => t.table == testTable)
  • The VIEW is ALSO returned (empty filter matched all types, not just TABLE). Assert.Contains(tables, t => t.table == testView)
METADATA-036 — Validates that GetPrimaryKeys and GetCrossReference reject a request that specifies a catalog but leaves the corresponding schema NULL.

Reproduce:

  • Call GetPrimaryKeys with catalog + table set and schema left NULL
  • Call GetCrossReference with foreign catalog + foreign table set and foreign schema left NULL

Expected (per the shared spec):

  • [sea] exactly 0 ExecuteStatement call(s)
  • full assertion contract:
protocol:
  thrift:
  - label: get_primary_keys
    error:
      contains:
      - assertion
      - failed
      - GET_FUNCTIONS
  - label: get_cross_reference
    error:
      contains:
      - assertion
      - failed
      - GET_FUNCTIONS
  sea:
  - label: get_primary_keys
    error:
      contains:
      - schema
      - 'null'
      - catalog
  - label: get_primary_keys
    sql_state: '42000'
  - label: get_cross_reference
    error:
      contains:
      - schema
      - 'null'
      - catalog
  - label: get_cross_reference
    sql_state: '42000'
  - call_count:
      operation: ExecuteStatement
      expected: 0
METADATA-037 — Validates that GetCrossReference treats a NULL foreign table as "unspecified" and returns an empty result (no error), even when the parent (PK) side IS fully specified.

Reproduce:

  • Call GetCrossReference with the parent (PK) side fully specified — catalog, schema
    and table — but the foreign table left NULL (foreign catalog and schema set).

Expected (per the shared spec):

  • completes without an exception
  • result has exactly 0 row(s)
  • [sea] exactly 0 ExecuteStatement call(s)
METADATA-038 — Validates the one exact-match key input where Thrift and SEA deliberately disagree: GetCrossReference with BOTH the parent table and the foreign table NULL.

Reproduce:

  • Call GetCrossReference with foreign catalog and foreign schema set but NEITHER the
    parent table nor the foreign table specified.

Expected (per the shared spec):

  • [sea] exactly 0 ExecuteStatement call(s)
  • full assertion contract:
protocol:
  thrift:
  - error:
      contains:
      - foreigntable
      - parenttablename
      - 'null'
  - sql_state: '42000'
  sea:
  - no_exception: true
  - row_count: 0
  - call_count:
      operation: ExecuteStatement
      expected: 0

Context

Lingua principale
TypeScript
Stelle
36
Fork
50
Merge medio
13h 46m
PR unite (30g)
9

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-nodejs

Tutte le issue di databricks/databricks-sql-nodejs

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.