Phixsura commented on PR #38698:
URL: https://github.com/apache/shardingsphere/pull/38698#issuecomment-4598900489

   3 条全修了,新 head `8c938b29` (rebased 在最新 master 上)。
   
   **P1.A 已修 (numeric→integer 走 round-away-from-zero)**
   `PostgreSQLCastEvaluator` 的 `castToShort` / `castToInteger` / `castToLong` 从 
`RoundingMode.HALF_EVEN` 换成 `RoundingMode.HALF_UP` (Java 的 HALF_UP 就是 
round-away-from-zero,跟 PG docs "numeric rounds ties away from zero" 一致)。javadoc 
重写,显式列出 `1.5::int4` → 2、`2.5::int4` → 3、`-2.5::int4` → -3。三层路径都加了 pin:
   - 
`PostgreSQLCastEvaluatorTest#assertBigDecimalPositiveTwoHalfRoundsAwayFromZero` 
/ `assertBigDecimalNegativeTwoHalfRoundsAwayFromZero` (evaluator 单元)
   - 
`ConditionValueTest#assertGetValueFromTypeCastOverBigDecimalPositiveTwoHalfRoundsAwayFromZero`
 / `assertGetValueFromTypeCastOverBigDecimalNegativeTwoHalfRoundsAwayFromZero` 
(WHERE cast 入口)
   - 
`InsertClauseShardingConditionEngineTest#assertCreateShardingConditionsWithTypeCastBigDecimalPositiveTwoHalfRoundsAwayFromZero`
 / 
`assertCreateShardingConditionsWithTypeCastBigDecimalNegativeTwoHalfRoundsAwayFromZero`
 (INSERT 路由路径)
   
   撤回 HALF_UP 改回 HALF_EVEN,两条 2.5 / -2.5 用例都失败 — 反向证明这俩 pin 是真在锁 rounding 
mode,不是巧合通过。
   
   **P1.B 已修 (typmod 目标整体不支持)**
   我选了你给的第二条路径 "treat modifier-bearing targets as unsupported"。`normalize()` 不再 
strip `(...)`,`VARCHAR(1)` / `CHAR(2)` / `NUMERIC(3,1)` 保留原样进 `categoryOf`,落到 
`OTHER` → `Optional.empty()`,caller 留着原 cast 不动,走 broadcast。javadoc 加了一段说明为什么不去 
parse typmod (character-length / precision-scale 语义路由路径不模型化)。反例:
   - evaluator: `assertStringToVarcharWithTypmodReturnsEmpty` 
(`"foo"::varchar(10)` → 
empty)、`assertOverLengthStringToVarcharWithTypmodReturnsEmpty` 
(`"ab"::varchar(1)` → empty)、`assertStringToCharWithTypmodReturnsEmpty` 
(`"ab"::char(2)` → 
empty)、`assertBigDecimalToNumericWithPrecisionScaleReturnsEmpty` 
(`1.55::numeric(3,1)` → empty)
   - INSERT 路径: 
`assertCreateShardingConditionsWithTypeCastTypmodTargetDoesNotRoute` 
(`?::varchar(1)` w/ "ab" → 空 condition list)
   - WHERE 路径: 
`assertCreateShardingConditionsForSelectCompareWithUnsupportedTypmodCastDoesNotRoute`
 (`?::numeric(3,1)` w/ 1.55 → 空 condition list)
   
   把 `normalize()` 还原回 strip-paren,4 条 typmod 反例全失败 — 反向证明 typmod 拒绝是真走到了 
`OTHER` 分支。
   
   **P2 已修 (WHERE 生产路径覆盖)**
   `WhereClauseShardingConditionEngineTest` 增了 4 条端到端用例,全部走 
`WhereClauseShardingConditionEngine.createShardingConditions` 
入口、`ExpressionExtractor.extractAndPredicates` / 
`ConditionValueGeneratorFactory.generate` 全链路:
   - `assertCreateShardingConditionsForSelectCompareWithCastedParameter`: `col 
= ?::int4` w/ String `"42"` → `ListShardingConditionValue.values = [Integer 
42]` (不是 String "42")
   - `assertCreateShardingConditionsForSelectInWithCastedParameter`: `col IN 
(?::int4)` w/ `"42"` → `[42]`
   - `assertCreateShardingConditionsForSelectBetweenWithCastedParameters`: `col 
BETWEEN ?::int4 AND ?::int4` w/ `"1"`, `"100"` → 
`RangeShardingConditionValue.range = [1, 100]`
   - 
`assertCreateShardingConditionsForSelectCompareWithUnsupportedTypmodCastDoesNotRoute`:
 `col = ?::numeric(3,1)` w/ `1.55` → `createShardingConditions` 返回空 list,生产路径上 
unsupported cast 不会瞎路由
   
   **验证**:
   - `./mvnw spotless:check checkstyle:check -pl features/sharding/core 
-Pcheck` 干净
   - `./mvnw test -pl features/sharding/core` 921/921 全绿,比上一轮 +11 条 
(PostgreSQLCastEvaluatorTest 32→35、ConditionValueTest 
12→15、InsertClauseShardingConditionEngineTest 
23→26、WhereClauseShardingConditionEngineTest 2→6)
   
   openGauss 这块我没补单独的语义证据 — 我们这版的 evaluator 实现是纯 Java 语义,不区分 PG / openGauss 
dialect,如果你想要单独的 openGauss e2e 我可以补一条。


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to