rahil-c commented on code in PR #13650:
URL: https://github.com/apache/hudi/pull/13650#discussion_r2356172605
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/keygen/ComplexAvroKeyGenerator.java:
##########
@@ -43,9 +45,16 @@ public ComplexAvroKeyGenerator(TypedProperties props) {
.map(String::trim)
.filter(s -> !s.isEmpty())
.collect(Collectors.toList());
- this.recordKeyFunction = ConfigUtils.getBooleanWithAltKeys(props,
COMPLEX_KEYGEN_OLD_ENCODING)
- ? record -> KeyGenUtils.getRecordKey(record, getRecordKeyFieldNames(),
isConsistentLogicalTimestampEnabled())
- : this::getRecordKeyWithoutKeyFieldNameOnSingleKeyField;
+ // Get table version
+ Integer tableVersionCode = ConfigUtils.getIntWithAltKeys(props,
WRITE_TABLE_VERSION);
+ HoodieTableVersion tableVersion =
HoodieTableVersion.fromVersionCode(tableVersionCode);
+ // Determine which encoding to use
+ boolean useNewEncodingForSingleKey =
tableVersion.lesserThan(HoodieTableVersion.NINE)
Review Comment:
Can you help me understand though why we need to give the user the option to
changing this encoding, i feel like this would create the same confusion again
with now some table versions NINE now having the "regression"/new encoding
which was just using fieldValue, vs what we want people to be using for nine
and above which is old encoding fieldName:fieldValue . Maybe im missing
something i guess on this migration path?
--
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]
