rangareddy commented on issue #17299:
URL: https://github.com/apache/hudi/issues/17299#issuecomment-5365818086
This issue was reviewed as part of the JIRA-migrated backlog triage
(HUDI-8429).
**Findings: confirmed, not done - and the existing documentation states the
gap.**
The strategy ID *is* persisted as a table config.
`hudi-common/src/main/java/org/apache/hudi/common/table/HoodieTableConfig.java:286`:
```java
public static final ConfigProperty<String> RECORD_MERGE_STRATEGY_ID =
ConfigProperty
.key("hoodie.record.merge.strategy.id")
.noDefaultValue()
.withAlternatives("hoodie.compaction.record.merger.strategy")
.sinceVersion("0.13.0")
.withDocumentation("Id of merger strategy. Hudi will pick
HoodieRecordMerger implementations in `"
+ RECORD_MERGE_IMPL_CLASSES_WRITE_CONFIG_KEY + "` which has the same
merger strategy id");
```
The implementation-class list is not.
`RECORD_MERGE_IMPL_CLASSES_WRITE_CONFIG_KEY` is defined at
`hudi-common/src/main/java/org/apache/hudi/common/config/HoodieReaderConfig.java:81`
as a **write/reader config**, supplied per job, and `HoodieTableConfig`
references it only inside that documentation string.
That doc string is effectively a statement of the bug: the table records
*which* merge strategy to use but not *where* to find an implementation of it,
so every engine and every job has to be told separately, and a reader that is
not told simply cannot merge correctly. For `CUSTOM` merge mode that is the
difference between a readable table and an unreadable one.
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]
