hudi-agent commented on code in PR #20346:
URL: https://github.com/apache/hudi/pull/20346#discussion_r4281075666
##########
hudi-common/src/main/java/org/apache/hudi/common/table/HoodieTableConfig.java:
##########
@@ -701,6 +701,11 @@ public static void create(HoodieStorage storage,
StoragePath metadataFolder, Pro
hoodieConfig.setValue(POPULATE_META_FIELDS,
Boolean.toString(metaFieldsMode.toLegacyPopulateMetaFields()));
}
+ String orderingFields =
hoodieConfig.getProps().getProperty(ORDERING_FIELDS.key());
+ if (orderingFields != null &&
tableVersion.lesserThan(HoodieTableVersion.NINE)) {
+ // readers of tables below version 9 only know the deprecated
precombine key, which the 9 to 8 downgrade writes too
+ hoodieConfig.setValue(PRECOMBINE_FIELD, orderingFields);
Review Comment:
🤖 It looks like a v6/v8 table created with several ordering fields (e.g.
`orderingFields = 'ts,seq'`) would now record
`hoodie.table.precombine.field=ts,seq`, which 0.x and 1.0.x read as a single
field name. On 1.0.2 the file group reader then throws `Field: ts,seq does not
exist in the table schema` for MOR slices with log files, where today it only
logs a warning and reads. Would it make sense to write the legacy key only when
there is exactly one ordering field?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
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]
