Skip to content

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

Description

@peco-engineer-bot

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions