LuciferYang opened a new issue, #10115: URL: https://github.com/apache/paimon/issues/10115
### Search before asking - [X] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Paimon version master ### Compute Engine Spark / Flink (`write.merge-schema` with type widening) ### Minimal reproduce step Create a table with a `MAP<INT, V>` column. Enable `write.merge-schema = true` and type widening, then write data whose same column is typed `MAP<BIGINT, V>`. The schema merge widens the map key from `INT` to `BIGINT`. After that, any scan, compaction, or stats read of a file written before the change fails. ### What doesn't meet your expectations? `SchemaMergingUtils.merge()` recursively merged the key type of a MAP column like any other nested type, so the key was widened from `INT` to `BIGINT`. The read layer cannot cast map keys: `SchemaEvolutionUtil.createMapCastExecutor` asserts `inputType.getKeyType().equals(targetType.getKeyType())` and throws `IllegalStateException` when they differ. So every pre-change file becomes unreadable, with a crash unrelated to the actual cause. The explicit `ALTER TABLE ... UPDATE COLUMN` path already rejects a map key type change; only the merge-schema path let it through. Expected: a map key type change is rejected up front with an actionable message, rather than silently producing an unreadable table. ### Anything else? Fix direction: `merge()` throws a descriptive `UnsupportedOperationException` when the base and update map key types differ (ignoring nullability, so a key that only changes nullability still merges). Map value types keep widening as before. ### Are you willing to submit a PR? - [X] I'm willing to submit a PR! -- 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]
