[coverage] Conformance findings: DATATYPE-042
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- sql, typescript
Research direction
Start with the DATATYPE-042 expected-failure test in the coverage PR under tests/, then compare the intended behavior with reference PR #644. Trace how databricks-sql-nodejs reports metadata for the two SELECT NULL queries. Done means both live and empty results report STRING for both columns, preserve names and null values, and satisfy the listed row-count assertions.
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-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
- DATATYPE-042 [sea]: SEA/kernel reports NULL_TYPE (TTypeId 16) for an untyped
SELECT NULL(VOID) result column instead of its STRING type, so it disagrees with aCAST(NULL AS STRING)sibling in the same result set; Thrift correctly reports STRING_TYPE- failing test:
untyped NULL column is reported as STRING, matching its CAST(NULL AS STRING) sibling [sea](see the coverage PR diff undertests/)
- failing test:
- DATATYPE-042: SEA/kernel reports NULL_TYPE (TTypeId 16) for an untyped
SELECT NULL(VOID) result column instead of its STRING type, so the column disagrees with aCAST(NULL AS STRING)sibling in the same result set; Thrift correctly reports STRING_TYPE
Reproduce & Expected
DATATYPE-042 — Verify that an UNTYPED NULL column -- a bare SELECT NULL expression, whose Databricks SQL type is VOID (spelled NULL on some surfaces) -- is reported by the driver as its STRING type, identically t…
Reproduce:
SELECT NULL AS untyped_null, CAST(NULL AS STRING) AS typed_null_string
SELECT NULL AS untyped_null, CAST(NULL AS STRING) AS typed_null_string FROM range(1) WHERE 1 = 0
Expected (per the shared spec):
- completes without an exception
- result has 2 column(s)
- col 0 is named
untyped_null - col 1 is named
typed_null_string - result has exactly 1 row(s)
- col
untyped_null, row 0 is null - col
typed_null_string, row 0 is null - completes without an exception
- result has 2 column(s)
- col 0 is named
untyped_null - col 1 is named
typed_null_string - result has exactly 0 row(s)
- full assertion contract:
result:
- label: live_data
no_exception: true
- label: live_data
column_count: 2
- label: live_data
column:
index: 0
name: untyped_null
- label: live_data
column:
index: 1
name: typed_null_string
- label: live_data
column_reported_type:
name: untyped_null
equals: STRING
- label: live_data
column_reported_type:
name: typed_null_string
equals: STRING
- label: live_data
column_reported_types_match:
columns:
- untyped_null
- typed_null_string
- label: live_data
row_count: 1
- label: live_data
column:
name: untyped_null
is_null: true
- label: live_data
column:
name: typed_null_string
is_null: true
- label: live_data
column_data_agrees_with_reported_type:
columns:
- untyped_null
- typed_null_string
- label: empty_result
no_exception: true
- label: empty_result
column_count: 2
- label: empty_result
column:
index: 0
name: untyped_null
- label: empty_result
column:
index: 1
name: typed_null_string
- label: empty_result
column_reported_type:
name: untyped_null
equals: STRING
- label: empty_result
column_reported_type:
name: typed_null_string
equals: STRING
- label: empty_result
column_reported_types_match:
columns:
- untyped_null
- typed_null_string
- label: empty_result
row_count: 0
Context
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/adbc-drivers/databricks/pull/644 — 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/1258
- Dominant language
- TypeScript
- Stars
- 36
- Forks
- 50
- Avg merge
- 13h 46m
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from databricks/databricks-sql-nodejs
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
engineer-bot
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
databricks/databricks-sql-nodejs#274 · 1 comment · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in databricks/databricks-sql-nodejs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
melgarafael/DeskcommCRM#1451 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bot:ai-assisted component:compact-js status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
midnightntwrk/midnight-sdk#403 ·