lvyanquan commented on code in PR #4473:
URL: https://github.com/apache/flink-cdc/pull/4473#discussion_r4062005850


##########
docs/content.zh/docs/core-concept/route.md:
##########
@@ -130,3 +130,66 @@ route:
 注意:基于正则捕获组的替换规则无法与 `replace-symbol` 选项搭配使用。
 
 {{< /hint >}}
+
+# 兼容性说明 — 多字符捕获组
+
+当 `source-table` 规则中使用了**可能匹配多字符的捕获组**时(典型示例是
+`new_db_6.table_([1-9]|1[0-6])`,它会同时匹配一位和两位数字后缀),路由行为在 Flink CDC 3.6.0
+和 3.7.0 之间存在差异。本节展示两种版本下的行为对比,并指出哪些已有任务在升级前需要关注。
+
+## Flink CDC 3.6.0 中的行为
+
+在 Flink CDC 3.6.0 中,当 source-table 正则包含可能匹配多字符的捕获组时,它实际上只会匹配
+source 表 id 的**前缀**;source 表 id 中未被匹配的尾部会被拼到 sink-table 模板之后,从而产生
+错误的 sink 表名。
+
+## Flink CDC 3.7.0 中的行为
+
+从 Flink CDC 3.7.0 起,source-table 正则会完整匹配整个 source 表 id,所有捕获组(包括跨越多字符的
+捕获组)都会被完整捕获。下表展示了同样的 source 表 id、同样的配置,在 3.6.0 与 3.7.0 中分别会被
+路由到哪里,便于直接对比。
+
+| Source 表 id         | source-table                              | sink-table 
                         | 3.6.0 中的路由结果                            | 3.7.0 
中的路由结果                       |
+|--------------------|-------------------------------------------|-------------------------------------|--------------------------------------------|-----------------------------------|
+| `new_db_6.table_1` | `new_db_6.table_([1-9]|1[0-6])`           | 
`new_db_6.table_$1_suffix`          | `new_db_6.table_1_suffix`                 
 | `new_db_6.table_1_suffix`         |
+| `new_db_6.table_13`| `new_db_6.table_([1-9]|1[0-6])`           | 
`new_db_6.table_$1_suffix`          | `new_db_6.table_1_suffix3`                
 | `new_db_6.table_13_suffix`        |
+| `new_db_6.table_17`| `new_db_6.table_([1-9]|1[0-6])`           | 
`new_db_6.table_$1_suffix`          | `new_db_6.table_1_suffix7`                
 | `new_db_6.table_17`(不匹配)         |

Review Comment:
   The `table_17` example in this compatibility table is not accurate. Although 
the old `resolveReplacement()` implementation would match the `table_1` prefix 
with `find()`, `calculateRoute()` first checks the rule with 
`Matcher.matches()`. Since `table_17` does not match either `[1-9]` or `1[0-6]` 
completely, `resolveReplacement()` is never invoked. Therefore, both 3.6.0 and 
the fixed version fall back to the original source table, `new_db_6.table_17`.
   
   The incorrect mapping `new_db_6.table_1_suffix7` would only be observed if 
`find()`/`replaceAll()` were invoked directly, not through 
`TableIdRouter.route()`. Please update this row and the related explanation 
about “partially matched” source tables accordingly.



-- 
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