voonhous commented on code in PR #19029:
URL: https://github.com/apache/hudi/pull/19029#discussion_r3664540481
##########
hudi-common/src/main/java/org/apache/hudi/common/config/HoodieCommonConfig.java:
##########
@@ -83,6 +83,15 @@ public class HoodieCommonConfig extends HoodieConfig {
+ " operation will fail schema compatibility check. Set this option
to true will make the missing "
+ " column be filled with null values to successfully complete the
write operation.");
+ public static final ConfigProperty<Boolean>
ALLOW_TIMESTAMP_PRECISION_EVOLUTION = ConfigProperty
+ .key("hoodie.write.schema.allow.timestamp.precision.evolution")
+ .defaultValue(false)
+ .markAdvanced()
+ .sinceVersion("1.3.0")
+ .withDocumentation("Controls whether schema evolution may change a
column between timestamp-millis and "
Review Comment:
Handled. The doc now spells out that this corrects the table schema only --
existing base files keep the old label, Hudi's reader compensates, and
Trino/Athena/BigQuery external/Spark-native parquet keep misreading them until
the files get rewritten via clustering or compaction. Framed as a one-time
migration: set the override, then rewrite.
The "1000x off" worry is gone with the redesign -- the per-field map
replaced the boolean, so a pin rescales the incoming longs
(`testReconcileTimestampLogicalTypeCoercesValuesOnPin`) and an unverified flip
throws.
Left #14161 out of the wording; "Hudi readers compensate for it" says the
same thing without pinning the doc to an issue number.
--
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]
