YashanDB|select 0.00 的返回类型居然变了? 警惕 JDBC 下的类型映射差异!

【问题描述】

在将应用从 Oracle 迁移到 YashanDB 后，开发人员发现相同 SQL：

SELECT 0.00 FROM dual;

在 Oracle 下返回 Float 类型，而在 YashanDB 下却被 JDBC 识别为 Integer 类型，导致 Java 应用解析异常、数据精度丢失，进而引发业务逻辑失败。

【触发条件】

查询中包含常量列 0.00;

使用 Java + JDBC 驱动获取 ResultSetMetaData;

依赖 precision 和 scale 判断返回值类型时，产生了误判。

【影响版本】

YashanDB 23.2.4.25 及以下版本;

Oracle JDBC 与 YashanDB JDBC 在处理未定义精度/刻度的 NUMBER 类型时行为不同。

【问题分析】

【问题分析】

1. Oracle 行为（JDBC）

Oracle 所有数值类型本质上都是 NUMBER 类型;

若未明确指定精度/刻度，JDBC 返回：

precision = 0

scale = -127

Java 应用判断 scale < 0.则默认映射为 Float，这是预期行为。

2. YashanDB 行为

同样的常量 0.00.YashanDB JDBC 返回的是整型;

实际返回结果 precision = 0、scale = -127.但底层处理逻辑不同，映射规则可能走到了 Integer 分支。

3. 导致问题的根因

常量列本身未指定明确数据类型;

JDBC 解析依赖 precision 与 scale 判断;

两种数据库处理 “未定义数值” 的行为存在差异，造成类型映射不一致。

【风险与影响】

Java 层接收类型不符，Float → Integer 导致数据失真;

查询结果不一致，影响数据准确性;

跨库迁移中容易被忽视，带来隐性错误。

【解决办法】

方法一：Java 层统一用 BigDecimal 接收

修改 Java 程序，将所有浮点型和整型常量结果均用 BigDecimal 处理：

BigDecimal result = resultSet.getBigDecimal(1);

避免依赖 JDBC 自动类型推断。

方法二：SQL 显式定义类型（推荐）

在 SQL 中强制指明常量类型，避免数据库自行推断：

SELECT CAST(0.00 AS NUMBER(10. 2)) FROM dual;

【迁移提醒】

Oracle → YashanDB 应用迁移过程中，务必注意：

【总结建议】

不要依赖 JDBC 默认推断的类型行为;

明确在应用层统一处理常量数据;

编写 SQL 时尽可能使用显式类型转换;

迁移测试中务必覆盖“常量列 + JDBC 类型解析”相关场景。