[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
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- backend-api-design, database
Hướng nghiên cứu
Start by locating DecimalParameter and the Thrift and SEA parameter binding paths, then inspect the named xfail tests in the coverage PR under tests/. Check how Decimal values are serialized and how precision is validated before execution. Done means exponent-form values bind as plain numerals with correct DECIMAL precision and scale, and values beyond maximum precision fail 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-python. 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-python) is fixed, then flips green as a tripwire.
Findings
- PARAMQUERY-022 [thrift]: DecimalParameter renders a bound DECIMAL's wire value as str(Decimal) and derives DECIMAL(p,s) by counting that string's characters, so Decimal("1e-7") is sent as value "1E-7" with type DECIMAL(4,0) and the server rounds the value to 0 instead of binding 0.0000001 as DECIMAL(7,7)
- failing test:
test_exponent_notation_decimal_parameter_binds_as_plain_numeral(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-022 [sea]: the connector sends a bound DECIMAL's value in exponent notation ("1E-7") on the SEA wire rather than the equivalent plain numeral "0.0000001"; the Rust kernel re-derives DECIMAL(7,7) so the value is NOT lost on SEA, but the plain-numeral wire form is not met (same str(Decimal) root cause as the Thrift truncation)
- failing test:
test_exponent_notation_decimal_parameter_binds_as_plain_numeral(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-023 [thrift]: the Thrift path performs no client-side precision validation for a bound DECIMAL: a 39-digit value is derived as DECIMAL(39,0) and sent, failing server-side with INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE (SQLSTATE 22023) instead of raising a bind-time parameter error before any ExecuteStatement, as the Rust-kernel/SEA path correctly does
- failing test:
test_decimal_parameter_beyond_maximum_precision_rejected_before_execution(see the coverage PR diff undertests/)
- failing test:
- PARAMQUERY-022: DecimalParameter renders a bound DECIMAL's wire value as str(Decimal) and derives DECIMAL(p,s) by counting that string's characters, so an exponent-form value is corrupted on Thrift: Decimal("1e-7") is sent as value "1E-7" with type DECIMAL(4,0) and the server rounds it to 0 (on SEA the Rust kernel re-derives DECIMAL(7,7) so the value survives, but "1E-7" still rides the wire instead of the plain numeral "0.0000001")
- PARAMQUERY-023: the Thrift path performs no client-side precision validation for a bound DECIMAL: a 39-digit value is derived as DECIMAL(39,0) and sent, so it fails server-side with INVALID_PARAMETER_MARKER_VALUE.INVALID_DATA_TYPE (SQLSTATE 22023) instead of raising a bind-time parameter error before any ExecuteStatement, as the Rust-kernel/SEA path correctly does
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-python; 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
- Python
- Star
- 236
- Fork
- 162
- Merge trung bình
- 13 giờ 13 phút
- Pull request đã merge (30 ngày)
- 23
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- 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-python
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
databricks/databricks-sql-python#1034 ·
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 72/100
databricks/databricks-sql-python#1012 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Token federation: `_exchange_token` raises KeyError('access_token') on error responses, discarding the real failure reasonCó thể đã có người làm @TangoEnSkai đã nhận 81 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
databricks/databricks-sql-python#904 ·
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 84/100
databricks/databricks-sql-python#865 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
engineer-bot
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
databricks/databricks-sql-python#860 · 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-python
Issue tương tự
-
Claiming namespace `kliklamala`Đang mởnamespace
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
EclipseFdn/open-vsx.org#15604 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
app: scripts severity: low status: backlog type: bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
netbox-community/netbox-scripts#164 ·
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 85/100
Maintainer thường phản hồi trong vòng 5 ngày
-
Public function to read participants.tsvCó thể đã có người làm @bruAristimunha đã nhận hôm nay. Đang mở
Độ 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ó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
huggingface/tau#799 ·
Maintainer thường phản hồi trong vòng 2 ngày