sundapeng commented on code in PR #8728:
URL: https://github.com/apache/paimon/pull/8728#discussion_r3610936970


##########
paimon-core/src/main/java/org/apache/paimon/utils/PartitionPathUtils.java:
##########
@@ -330,8 +455,9 @@ public static List<Pair<LinkedHashMap<String, String>, 
Path>> searchPartSpecAndP
                                         part.getPath(), partitionKeys),
                                 part.getPath()));
             } else {
-                LinkedHashMap<String, String> spec = 
extractPartitionSpecFromPath(part.getPath());
-                if (spec.size() != partitionKeys.size()) {
+                LinkedHashMap<String, String> spec =
+                        extractPartitionSpecFromPath(part.getPath(), 
partitionKeys);

Review Comment:
   🟡 **[minor] migration — 严格 key 匹配可能静默隐藏已有分区**
   
   searchPartSpecAndPaths 现在使用带 partitionKeys 参数的 
extractPartitionSpecFromPath,要求每个路径组件的 key 与声明的分区键精确匹配。旧代码使用无参版本,接受任意 k=v 
组件仅检查数量。
   
   受影响的场景:
   1. 通过 ALTER TABLE 重命名分区键后,旧目录保留旧 key 名
   2. 外部 format table 指向 Hive 风格目录,key 大小写不同(如 `DT=20240101` vs 声明的 `dt`)
   3. 外部工具创建的目录使用缩写 key 名
   
   这些分区以前可见(虽然 spec 值可能不正确),现在变为不可见,导致查询结果中**静默数据丢失**。
   
   **建议**: 当目录因 key 不匹配被跳过时记录 WARN 日志(类似 managed table 的 corrupt-partition 
警告),以便运维人员发现数据不可见问题。考虑大小写不敏感的 key 匹配以对齐 Hive 语义。在文档中说明此变更后分区目录必须精确匹配声明的 key 名。



##########
paimon-core/src/main/java/org/apache/paimon/rest/RESTCatalog.java:
##########
@@ -567,8 +575,13 @@ public void createTable(Identifier identifier, Schema 
schema, boolean ignoreIfEx
             checkNotBranch(identifier, "createTable");
             checkNotSystemTable(identifier, "createTable");
             validateCreateTable(schema, dataTokenEnabled);
-            createExternalTablePathIfNotExist(schema);
             tableDefaultOptions.forEach(schema.options()::putIfAbsent);

Review Comment:
   🟡 **[minor] migration — catalog 级 table-default 选项参与 managed format table 
校验,可能破坏现有工作流**
   
   在 RESTCatalog.createTable 
中,`tableDefaultOptions.forEach(schema.options()::putIfAbsent)` 现在在 
`validateManagedFormatTableOptions` 和 `validateManagedFormatTableCatalog` 
**之前**执行。
   
   如果 REST catalog 配置了 
`table-default.metastore.partitioned-table=true`(对于希望所有表都进行分区管理的组织来说是合理配置),则:
   1. 使用 `format-table.implementation=engine` 创建 format table 将失败(即使用户从未显式设置 
partitioned 选项)
   2. 创建外部 format table(带 PATH)将失败(must be an internal table)
   
   replaceTable(第 661-667 行)同理。这对依赖 catalog 默认值对 format table 不生效的现有 SQL 
工作流是**破坏性变更**。
   
   **建议**: 仅对用户在建表语句中显式设置的选项执行 managed format table 校验,而非 catalog 级默认值。或者跟踪哪些 
key 是用户指定的 vs 默认注入的,跳过默认注入的校验。至少在文档中说明设置 
`table-default.metastore.partitioned-table=true` 将拒绝 engine 实现或外部路径的 format 
table。



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