[coverage] Conformance findings: METADATA-028,METADATA-035,METADATA-036,METADATA-037,METADATA-038
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Pouca atividade
- Stack de tecnologia
- node.js, sql, typescript
Direção de pesquisa
Comece pelos testes de reprodução METADATA-028, METADATA-035, METADATA-036, METADATA-037 e METADATA-038 no coverage PR em tests e, em seguida, rastreie os pontos de entrada GetPrimaryKeys, GetTables e GetCrossReference neste connector. Use os resultados esperados e as asserções da contagem de chamadas a ExecuteStatement como critérios de conclusão, incluindo a diferença documentada entre Thrift e SEA.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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
ExecuteStatementcall(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
ExecuteStatementcall(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
ExecuteStatementcall(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
ExecuteStatementcall(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
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/adbc-drivers/databricks/pull/609 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
- Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1093
- Linguagem predominante
- TypeScript
- Estrelas
- 36
- Forks
- 50
- Merge médio
- 13h 46min
- PRs com merge (30d)
- 9
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de databricks/databricks-sql-nodejs
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
-
Docs folder deleted in 1.8.4 Abertaengineer-bot
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
databricks/databricks-sql-nodejs#274 · 1 comentário · 1 reação ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 68/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
Todas as issues de databricks/databricks-sql-nodejs
Issues semelhantes
-
S: triage
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 85/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Abertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
GauravKarakoti/SecureFlow#1070 · 1 comentário ·
-
feature:Languages/Translations good first issue ready Web
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
digitalfabrik/integreat-app#4394 ·