[coverage] Conformance findings: PARAMQUERY-022,PARAMQUERY-023

未关闭
  • 哪里不对？
#547 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
54/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
databases, go
领域
backend, database

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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 under tests/)
  • 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 under tests/)
  • 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 under tests/)
  • 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 under tests/)
  • 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

主要语言
Go
星标
54
派生
71
平均合并
16 小时 3 分钟
30 天内合并 PR
21

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

databricks/databricks-sql-go 的其他 Issue

查看 databricks/databricks-sql-go 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。