[coverage] Conformance findings: PARAMQUERY-022,PARAMQUERY-023
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 54/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Go
- Star
- 54
- Fork
- 71
- Merge trung bình
- 16 giờ 3 phút
- Pull request đã merge (30 ngày)
- 21
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của databricks/databricks-sql-go
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
databricks/databricks-sql-go#494 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 66/100
databricks/databricks-sql-go#546 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 52/100
databricks/databricks-sql-go#521 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 56/100
databricks/databricks-sql-go#520 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
engineer-bot
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 49/100
databricks/databricks-sql-go#517 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của databricks/databricks-sql-go
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
coder/openstorage#807 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
coder/coder-logstream-kube#255 · 1 bình luận ·
-
kind/features
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
TencentBlueKing/bk-nodemgr#3991 ·
Maintainer thường phản hồi trong vòng 1 ngày