collado-mike commented on code in PR #724:
URL: https://github.com/apache/polaris/pull/724#discussion_r1920470791
##########
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:
I think moving the credentials generation into the `FileIOFactory` makes a
ton of sense. And, IMO, makes for a much more cohesive and sensible design than
simply passing in the the table properties. I'd be in favor of changing the
signature of `FileIOFactory` to take in all of the params necessary to generate
credentials, then custom implementations can also do whatever they want with
table properties.
I would change that signature, though, to take in the whole
`TableLikeEntity`, rather than just the `tableProperties`. It's unclear from
that signature whether the externally exposed properties field is being used or
if it's the `internalProperties`. I can imagine scenarios where both/either are
needed by the factory.
--
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]
