danny0405 commented on code in PR #19205:
URL: https://github.com/apache/hudi/pull/19205#discussion_r3782665101
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/config/HoodieWriteConfig.java:
##########
@@ -3587,11 +3632,102 @@ public Builder withCanIgnorePostCommitFailures(boolean
canIgnorePostCommitFailur
return this;
}
+ /**
+ * @deprecated since 1.3.0, use {@link
#withMetaFieldsMode(MetaFieldsMode)} instead
+ * ({@code true} maps to {@link MetaFieldsMode#ALL}, {@code false} to
{@link MetaFieldsMode#NONE}).
+ */
+ /**
+ * Whether this builder's own {@code withPopulateMetaFields} / {@code
withMetaFieldsMode} setters were
+ * called, as opposed to the value arriving through {@code withProperties}
/ {@code withProps}.
+ *
+ * <p>The two are indistinguishable once written into the config, but they
mean very different
+ * things. A caller that sets both on this builder and contradicts itself
should be told. A caller
+ * that sets one while the other rides in on an inherited props blob is
not contradicting anything
+ * -- it is overriding, which is what a setter is for.
+ */
+ private Boolean statedPopulateMetaFields = null;
Review Comment:
can we eliminate these two booleans, it looks verbose and complicated, even
if there is discrepency for explicit API setup and `withProps`, we can still
check the property set up using the `contains` since the inference happens at
the last step of all the setup?
--
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]
