rangareddy commented on issue #17295: URL: https://github.com/apache/hudi/issues/17295#issuecomment-5365816739
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-8418). **Findings: not done, and the linked PR is closed without merging.** PR #12868 (`[HUDI-8418] Throw an error if the table configs of record merge are about to change`) is **closed and unmerged**. A closed-unmerged PR is not a fix, so the `status:pr-available` label on this issue is now misleading - it implies a live patch is waiting for review when there is none. Worth removing or re-pointing. The guard itself does not exist on `master`. I looked for an immutability check keyed on `RECORD_MERGE_MODE` or `RECORD_MERGE_STRATEGY_ID`: - nothing in the table-config code under `hudi-common/src/main/java/org/apache/hudi/common/table/` - nothing in `HoodieWriterUtils.validateTableConfig` (`hudi-spark-datasource/hudi-spark-common/src/main/scala/org/apache/hudi/HoodieWriterUtils.scala:228`, `:263`), which is the only table-config validation entry point on the Spark write path - and `HoodieTableConfig.update()` is an unconditional upsert, so nothing blocks the write at the storage layer either **This overlaps two other open issues** that are the same underlying problem - the safety of mutating merge configuration after table creation: - #17339 (HUDI-8731) - forbid merge mode change in table config - #17336 (HUDI-8702) - `table update-configs` leaves `hoodie.record.merge.strategy.id` stale when payload class or merge mode change A single design covering "which merge configs are immutable, which are derived, and what happens on an attempted change" would resolve all three. Doing them independently risks three inconsistent checks. Keeping this open. -- 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]
