eric-maynard commented on code in PR #724:
URL: https://github.com/apache/polaris/pull/724#discussion_r1919329964
##########
service/common/src/main/java/org/apache/polaris/service/catalog/BasePolarisCatalog.java:
##########
@@ -1627,6 +1627,12 @@ private FileIO refreshIOWithCredentials(
// the credentials should always override table-level properties, since
// storage configuration will be found at whatever entity defines it
tableProperties.putAll(credentialsMap);
+
+ // Populate the internal properties to FileIO in case the FileIO
implementation needs them
+ Map<String, String> internalProperties =
+
storageInfoEntity.map(PolarisEntity::getInternalPropertiesAsMap).orElse(Map.of());
Review Comment:
On the contrary, I actually think having the FileIO take unstructured data
aligns well with our current model and best supports pluggability.
Polaris (Iceberg) table properties are a `Map<String, String>`, and FileIO's
`properties` returns a `Map<String, String>`. Forcing this map through some
type like `PolarisCatalogConfig` seems unnecessary and limiting.
If someone wants to bring their own FileIO implementation and configure some
table to interact with it, I would prefer if Polaris could support that without
any code changes needed.
--
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]
