[coverage] Conformance findings: PARAMQUERY-019,PARAMQUERY-021

Bắt đầu với hai bài kiểm thử conformance bị lỗi được nêu tên trong diff tests/ của coverage PR, sau đó so sánh hành vi mong đợi của chúng với reference PR #167. Truy vết đường dẫn liên kết tham số Thrift của TypeScript driver đối với các giá trị DECIMAL; hoàn tất khi cả hai xfail test PARAMQUERY-019 và PARAMQUERY-021 đều chuyển sang green mà không bị cắt ngắn phần giá trị thập phân.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. 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-nodejs) is fixed, then flips green as a tripwire.

Findings

• PARAMQUERY-019 [thrift]: Thrift DECIMAL target case of the coercion table truncates the bound value ("123.45" -> 123) — same bind-side scale loss as PARAMQUERY-021; all other declared targets (INTEGER/BIGINT/DOUBLE/STRING/DATE/TIMESTAMP) conform
  • failing test: target-type coercion — the declared target type, not the source string, drives the result column type [thrift] (see the coverage PR diff under tests/)
• PARAMQUERY-021 [thrift]: Thrift bind of a DECIMAL-typed DBSQLParameter with a scale-less target silently truncates fractional digits ("123.45" returns 123, "123.4567" returns 123) — silent numeric data loss with no error; SEA preserves the value correctly
  • failing test: under-specified DECIMAL target — fractional digits survive, never silently truncated [thrift] (see the coverage PR diff under tests/)

Reproduce & Expected

PARAMQUERY-019 — Verify setObject() coerces string "123" to integer

Reproduce:

SELECT ? AS int_value
SELECT ? AS v

PARAMQUERY-021 — Verify that declaring a DECIMAL/NUMERIC target type WITHOUT a scale never causes the driver to silently drop the fractional digits of the bound value.

Reproduce:

SELECT ? AS decimal_value
SELECT ? AS decimal_value

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/167 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; 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/1317