[coverage] Conformance findings: PARAMQUERY-021 (#1599)

[peco-engineer-bot]

Summary

Automated fix for #1599 — [coverage] Conformance findings: PARAMQUERY-021.

Fixed DatabricksTypeUtil.getDatabricksTypeFromSQLType so Types.FLOAT maps to the 8-byte Databricks DOUBLE (JDBC spec Appendix B: FLOAT is a synonym for DOUBLE), while Types.REAL alone maps to the 4-byte FLOAT. Verified against the live warehouse via the e2e test (SELECT ? AS v with setObject Types.FLOAT now yields a DOUBLE result column, distinct from Types.REAL which yields FLOAT) and the unit-level mapping guard.

Root cause & plan

Root cause: DatabricksTypeUtil.getDatabricksTypeFromSQLType() maps BOTH Types.FLOAT and Types.REAL to the Databricks 4-byte FLOAT wire type (DatabricksTypeUtil.java:477-479). Per the JDBC spec (Appendix B type table), Types.FLOAT is a synonym for DOUBLE (8-byte double precision, Java double); only Types.REAL is 4-byte single precision (Java float). So a setObject(i, x, Types.FLOAT) bind is silently narrowed to single precision instead of riding as the 8-byte DOUBLE the spec requires. This mapping feeds DatabricksPreparedStatement.setObject(int,Object,int) (line 339) which stores the parameter's ColumnInfoTypeName and sends the type string on the wire (mapToSparkParameterListItem / mapToParameterListItem); for SELECT ? AS v the server echoes the bound param type as the result column type, making the narrowing observable end-to-end.
Files: jdbc-core/src/main/java/com/databricks/jdbc/common/util/DatabricksTypeUtil.java, jdbc-core/src/test/java/com/databricks/jdbc/common/util/DatabricksTypeUtilTest.java, jdbc-core/src/test/java/com/databricks/jdbc/integration/e2e/ParameterBindTypeTests.java
Planned coverage:

• Live e2e (integration/e2e): run SELECT ? AS v binding a double value with setObject(1, x, Types.FLOAT); assert the result column type is Types.DOUBLE (8-byte double, the wire type Types.FLOAT must ride as per JDBC spec), and contrast with a Types.REAL bind of the same value which must yield Types.FLOAT — demonstrating the declared target type drives the wire type and that FLOAT and REAL no longer collapse. Also assert the DOUBLE-bound value round-trips at double precision. (Types.FLOAT target must ride as the 8-byte Databricks DOUBLE, not the 4-byte FLOAT (and must differ from Types.REAL).)
• Unit: correct the existing DatabricksTypeUtilTest.testGetDatabricksTypeFromSQLType assertion that encodes the wrong mapping (Types.FLOAT -> FLOAT). After the fix it must assert Types.FLOAT -> DatabricksTypeUtil.DOUBLE while Types.REAL -> DatabricksTypeUtil.FLOAT stays. Authority: JDBC spec Appendix B (FLOAT<->double, REAL<->float). This is an existing test that encodes wrong behavior and must change; not a silent flip. (Unit-level mapping guard for getDatabricksTypeFromSQLType.)

Files changed

• src/test/java/com/databricks/jdbc/integration/e2e/ParameterBindTypeTests.java
• src/test/java/com/databricks/jdbc/common/util/DatabricksTypeUtilTest.java
• src/main/java/com/databricks/jdbc/common/util/DatabricksTypeUtil.java

Test plan

• com.databricks.jdbc.integration.e2e.ParameterBindTypeTests#testTargetTypeDrivesWireTypeAcrossScalarTypes — fails (red) against the original code, passes (green) after the fix
• com.databricks.jdbc.common.util.DatabricksTypeUtilTest#testGetDatabricksTypeFromSQLType — fails (red) against the original code, passes (green) after the fix

NO_CHANGELOG=true

🤖 Generated by engineer-bot (bug-fix flow) — review before merge.

[peco-review-bot]

✅ No issues identified by the review bot.