hudi-agent commented on code in PR #19205:
URL: https://github.com/apache/hudi/pull/19205#discussion_r3763392590
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/BaseHoodieWriteClient.java:
##########
@@ -1544,13 +1550,83 @@ protected boolean loadActiveTimelineOnTableInit() {
return true;
}
+ /**
+ * Adopt the table's {@code hoodie.meta.fields.mode} when this writer did
not state one.
+ *
+ * <p>The mode is a table property: it is settable at table creation,
through hudi-cli, or by an
+ * upgrade, and never by an ordinary write. Callers routinely build a write
config without
+ * restating the table's meta-field settings — table services do, and so
does a restarted
+ * StreamSync — and such a writer must write what the table already
advertises rather than silently
+ * narrowing it. Without this, an unstated writer resolves to {@code NONE}
(via the deprecated
+ * {@code hoodie.populate.meta.fields} fallback) and writes null meta
columns into a table whose
+ * earlier files have them populated.
+ *
+ * <p>Inheritance applies only when the writer states <em>neither</em>
property. If it explicitly
+ * set the mode or the deprecated boolean, that value is left alone so the
comparison below can
+ * reject it on a mismatch: a user who deliberately passed {@code
populate.meta.fields=false}
+ * against an {@code ALL} table should be told the setting conflicts, not
have it silently
+ * overridden.
+ *
+ * <p>Called explicitly from {@link #initTable} rather than from
+ * {@link #validateAgainstTableProperties}: resolving what this writer will
use is a separate
+ * concern from checking it, and a method named "validate" must not quietly
rewrite the config it
+ * is handed. Read-only entry points that only validate (marker deletion,
dry-run partition
+ * listing) therefore do not resolve, which is correct -- they write no
records.
Review Comment:
🤖 Now that resolve moved into `initTable`, the two callers that validate
without it — `SparkMain.deleteMarker` and `HoodieDropPartitionsTool.dryRun` —
build a default-`ALL` write config, so on a `COMMIT_TIME_ONLY`/`NONE` table
`validateAgainstTableProperties` hits the "cannot be widened" throw. Is that
intended for these read-only maintenance ops? The "they write no records"
reasoning covers inheritance, but the risk here is a false-positive throw
rather than a bad write.
<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]
