You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by "hudi-bot (via GitHub)" <gi...@apache.org> on 2025/11/30 13:35:41 UTC
[I] Improve the format of record merge strategy ID [hudi]
hudi-bot opened a new issue, #17297:
URL: https://github.com/apache/hudi/issues/17297
[https://github.com/apache/hudi/pull/11943#discussion_r1809697340]
Could we make the ID easier to read, e.g.,
"00000000-0000-0000-0000-000000000000": Avro payload based merging;
"00000000-0000-0000-0000-000000000001": overwrite with latest;
"00000000-0000-0000-0000-000000000002": event time ordering / default hoodie payload. Still reserve the existing ID as an alternative ID;
"00000000-0000-0000-0000-000000000003": validate duplicate key record merger;
etc.
Also is it necessary to use UUID format, maybe "0", "1", "2" are shorter IDs?
Another problem is, In the current scheme, it's still hard to avoid collision, since there is no rule on how to generate these IDs. A general String with namespace and number might be better.
## JIRA info
- Link: https://issues.apache.org/jira/browse/HUDI-8422
- Type: Sub-task
- Parent: https://issues.apache.org/jira/browse/HUDI-9108
- Fix version(s):
- 1.1.0
--
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: commits-unsubscribe@hudi.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Improve the format of record merge strategy ID [hudi]
Posted by "rangareddy (via GitHub)" <gi...@apache.org>.
rangareddy commented on issue #17297:
URL: https://github.com/apache/hudi/issues/17297#issuecomment-5365817423
This issue was reviewed as part of the JIRA-migrated backlog triage (HUDI-8422).
**Findings: not adopted. The IDs are still opaque random UUIDs.**
On `master`, `hudi-common/src/main/java/org/apache/hudi/common/model/HoodieRecordMerger.java`:
```java
:50 String EVENT_TIME_BASED_MERGE_STRATEGY_UUID = "eeb8d96f-b1e4-49fd-bbf8-28ac514178e5";
:53 String COMMIT_TIME_BASED_MERGE_STRATEGY_UUID = "ce9acb64-bde0-424c-9b91-f6ebba25356d";
:56 String CUSTOM_MERGE_STRATEGY_UUID = "1897ef5f-18bc-4557-939c-9d6a8afd1519";
:59 String PAYLOAD_BASED_MERGE_STRATEGY_UUID = "00000000-0000-0000-0000-000000000000";
```
So only the payload-based strategy uses the readable all-zeros form proposed here; the other three are still random UUIDs, exactly the state the ticket objects to.
The constraint to keep in mind when acting on it: these values are persisted in `hoodie.properties` as `hoodie.record.merge.strategy.id`, so renumbering is an on-disk compatibility change and existing tables must keep resolving. The ticket already anticipates that ("Still reserve the existing ID as an alternative ID"), which is the right shape - the `withAlternatives` mechanism on `RECORD_MERGE_STRATEGY_ID` is where that would live.
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: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org