[coverage] Conformance findings: PARAMQUERY-022,PARAMQUERY-023
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 54/100
Research direction
Read the coverage PR diff under tests/ and the reference PR for the intended behavior. Trace where DECIMAL parameter precision and scale are derived in the Go driver, including the shared path used by Thrift and SEA/kernel. The two named failing tests should pass: exponent notation binds as a plain numeral with the correct scale, and precision above 38 is rejected before ExecuteStatement.
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-go. 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-go) is fixed, then flips green as a tripwire.
Findings
- PARAMQUERY-022 [thrift]: Exponent-notation DECIMAL parameter sent verbatim as "1e-7" and typed DECIMAL(4,0) — (p,s) derived from the exponent string's characters, not the value, so the value is bound at scale 0 and lost.
- failing test:
TestExponentNotationDecimalParameterBindsAsPlainNumeral(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-022 [sea]: Exponent-notation DECIMAL parameter sent verbatim as "1e-7" and typed DECIMAL(4,0) on the SEA/kernel path too — the mis-derivation is in the Go driver, above the backend split.
- failing test:
TestExponentNotationDecimalParameterBindsAsPlainNumeral(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-023 [thrift]: A 39-digit DECIMAL parameter is not validated client-side: the driver sends DECIMAL(39,0) and the statement fails server-side with INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE instead of a bind-time parameter error (spec requires 0 ExecuteStatement).
- failing test:
TestDecimalParameterBeyondMaximumPrecisionRejectedBeforeExecution(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-023 [sea]: Same missing bind-time 38-digit precision validation on the SEA/kernel path: DECIMAL(39,0) is sent and the kernel surfaces the server's INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE (BAD_REQUEST) instead of a client-side parameter error.
- failing test:
TestDecimalParameterBeyondMaximumPrecisionRejectedBeforeExecution(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-022: A DECIMAL-typed parameter whose value string is in exponent notation is sent verbatim ("1e-7") and typed DECIMAL(4,0) — (precision, scale) is derived from the exponent form's characters instead of the value, so the server binds a scale-0 decimal and the value is lost; affects both the Thrift and SEA/kernel paths. It should be rewritten as the equivalent plain numeral with the derived scale (0.0000001 / DECIMAL(7,7)), as it already does correctly for plain numerals.
- PARAMQUERY-023: A DECIMAL parameter needing more than Databricks' maximum 38 digits of precision is not rejected at bind time: the driver sends DECIMAL(39,0) and the statement fails server-side with [INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE] "the given data type 'DECIMAL(39,0)' for parameter 'null' is not valid" (SQLSTATE 22023) instead of raising a client-side parameter error before any ExecuteStatement; affects both the Thrift and SEA/kernel paths.
Context
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-nodejs/pull/585 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; 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/2022
- Dominant language
- Go
- Stars
- 54
- Forks
- 71
- Avg merge
- 16h 3m
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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-go
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
databricks/databricks-sql-go#494 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 66/100
databricks/databricks-sql-go#546 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 1-2 days Newbie friendliness 52/100
databricks/databricks-sql-go#521 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 1-2 days Newbie friendliness 56/100
databricks/databricks-sql-go#520 ·
Maintainers usually reply within 1 day
-
engineer-bot
Difficulty 4/5 3-5 days Newbie friendliness 49/100
databricks/databricks-sql-go#517 · 3 comments ·
Maintainers usually reply within 1 day
All issues in databricks/databricks-sql-go
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
kind/features
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
TencentBlueKing/bk-nodemgr#3991 ·
Maintainers usually reply within 1 day
-
meta
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
last9/last9-mcp-server#554 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Plain-http federation signing external_url fails startup with "invalid federation request signature"Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day