[coverage] Conformance findings: DATATYPE-042

[peco-engineer-bot]

Summary

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

Findings

• DATATYPE-042 [thrift, sea]: ResultSet.getBigDecimal(int,int) rounds HALF_UP instead of truncating toward zero on a lossy down-rescale and raises no fractional-truncation warning (01S07) on getWarnings(); getBigDecimal(String,int) also discards its scale argument so the by-name and by-index paths disagree
  • failing test: testDecimalReadAtAnApplicationRequestedScale (see the coverage PR diff under tests/)
• DATATYPE-042: ResultSet.getBigDecimal(int,int) rounds HALF_UP instead of truncating toward zero on a lossy down-rescale and raises no fractional-truncation warning (01S07) on getWarnings(), so a truncating DECIMAL read is indistinguishable from an exact one; separately getBigDecimal(String,int) discards its scale argument and answers at the column's declared scale, so the by-name and by-index paths disagree

Reproduce & Expected

DATATYPE-042 — Verify that when an application reads a DECIMAL column at a target scale of its OWN choosing -- rather than the column's declared scale -- the driver rescales the value and classifies the outcome cor…

Expected (per the shared spec):

• result has exactly 1 row(s)
• col d_exact, row 0 == 123.45
• col d_truncates, row 0 == 123.99
• col d_negative, row 0 == -123.46
• full assertion contract:

result:
- row_count: 1
- column:
    name: d_exact
    equals: 123.45
- column:
    name: d_truncates
    equals: 123.99
- column:
    name: d_negative
    equals: -123.46
- decimal_read_at_requested_scale:
    cases:
    - column: d_exact
      precision: 10
      scale: 2
      value: 123.45
      reported_scale: 2
      warning: none
    - column: d_exact
      precision: 10
      scale: 3
      value: 123.45
      reported_scale: 3
      warning: none
    - column: d_exact
      precision: 10
      scale: 1
      value: 123.4
      reported_scale: 1
      warning: truncation
      sql_state: 01S07
    - column: d_truncates
      precision: 10
      scale: 1
      value: 123.9
      reported_scale: 1
      warning: truncation
      sql_state: 01S07
    - column: d_truncates
      precision: 10
      scale: 0
      value: 123
      reported_scale: 0
      warning: truncation
      sql_state: 01S07
    - column: d_negative
      precision: 10
      scale: 1
      value: -123.4
      reported_scale: 1
      warning: truncation
      sql_state: 01S07
    - column: d_exact
      precision: 2
      scale: 2
      error: out_of_range
      sql_state: '22003'
    - column: d_exact
      precision: 40
      scale: 2
      value: 123.45
      reported_scale: 2
      warning: none
    - column: d_exact
      precision: 10
      scale: 40
      error: invalid_scale
      sql_state: HY104
- decimal_truncation_warning_reaches_application:
    columns:
    - d_exact
    - d_truncates
    - d_negative
    sql_state: 01S07
    paths:
    - bound_column
    - get_data

Context

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