[coverage] Conformance findings: DATATYPE-043

Open
  • Is something wrong?
#1,770 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
database

Research direction

Start with the testUntypedNullColumnReportedAsString xfail in the coverage PR under tests/, then trace how this JDBC driver builds ResultSetMetaData.getColumnTypeName() for an untyped NULL. Compare the reported type with the typed NULL sibling and the existing normalizations mentioned in the issue. Done when the untyped NULL reports STRING on both thrift and SEA and the conformance assertions pass.

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-jdbc. 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-jdbc) is fixed, then flips green as a tripwire.

Findings

  • DATATYPE-043 [thrift, sea]: getColumnTypeName() reports "VOID" for an untyped NULL column instead of the driver's STRING type name, while getColumnType() for the same column is correctly Types.VARCHAR and the CAST(NULL AS STRING) sibling reports "STRING"
    • failing test: testUntypedNullColumnReportedAsString (see the coverage PR diff under tests/)
  • DATATYPE-043: ResultSetMetaData.getColumnTypeName() returns the raw server type name "VOID" for an untyped NULL column (SELECT NULL) on both thrift and SEA, while getColumnType() for that same column is correctly Types.VARCHAR and a CAST(NULL AS STRING) sibling reports "STRING" — so the column is type-distinguishable from an equivalent STRING column and schema-mirroring consumers see an unbindable VOID type; columnTypeText should be normalised to "STRING" as it already is for geospatial-disabled and TIMESTAMP_NTZ columns

Reproduce & Expected

DATATYPE-043 — Verify that an UNTYPED SQL NULL column -- SELECT NULL AS c, whose Databricks logical type is VOID -- is reported through the driver's result type-metadata surface as the driver's STRING type: the S…

Expected (per the shared spec):

  • result has exactly 1 row(s)
  • result has 3 column(s)
  • col untyped_null, row 0 is null
  • col typed_null_string, row 0 is null
  • col typed_int, row 0 == 1
  • full assertion contract:
result:
- row_count: 1
- column_count: 3
- reported_column_type:
    column: untyped_null
    same_as_column: typed_null_string
- reported_column_type:
    column: untyped_null
    sql_type: STRING
- reported_column_type:
    column: typed_int
    sql_type: INT
- column:
    name: untyped_null
    is_null: true
- column:
    name: typed_null_string
    is_null: true
- column:
    name: typed_int
    equals: 1

Context

Dominant language
Java
Stars
41
Forks
49
Avg merge
1d 7h
Merged PRs (30d)
27

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/databricks-jdbc

All issues in databricks/databricks-jdbc

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.