wombatu-kun opened a new pull request, #16608: URL: https://github.com/apache/iceberg/pull/16608
## Summary `SnowflakeCatalog.initialize(String, Map)` adds the JDBC `application` and `user_agent_suffix` identifiers by calling `properties.put(...)` directly on the caller-supplied map. This has two problems: it throws `UnsupportedOperationException` when the caller passes an immutable map (for example `Map.of(...)` or `ImmutableMap.of(...)`, which is a contract-legal and idiomatic way to call `Catalog.initialize`), and even with a mutable map it silently pollutes the caller's map with the two derived JDBC properties. Every other catalog (`JdbcCatalog`, `GlueCatalog`, `DynamoDbCatalog`, `HadoopCatalog`, `InMemoryCatalog`) treats the input properties as read-only and copies them. This change makes `SnowflakeCatalog` do the same: it builds a mutable copy with `Maps.newHashMap(properties)`, adds the JDBC identifiers to the copy, and passes the copy to the JDBC client pool and catalog initialization, leaving the caller's map untouched. ## Tests Added two tests to `TestSnowflakeCatalog`: `testInitializeWithImmutableProperties` verifies that initializing with an immutable properties map no longer throws, and `testInitializeDoesNotMutateCallerProperties` verifies that a mutable caller map is left unmodified after `initialize`. Both fail before this change and pass after. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
