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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
