dennishuo commented on code in PR #724:
URL: https://github.com/apache/polaris/pull/724#discussion_r1917570035


##########
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:
   The intent of `internalProperties` really is to have room for some 
Polaris-internal persistence items that don't *directly* interface with any 
kind of external code, but rather are contained by some Polaris-specific 
interpretation layer. So, I'm not sure an allowlist is enough because it still 
mixes the domain of config keys that show up in `internalProperties` with the 
domain of config keys that happen to be Iceberg-recognizable properties.
   
   Indeed, some internalProperties are translated into "top-level" structured 
fields in REST objects, others only control internal behaviors, etc.
   
   So, my thinking here is we should probably be explicit about what we're 
trying to do. Specifically, we are trying to give *additional* internal 
contextual information to a `FileIOFactory.loadFileIO` call (a Polaris 
construct) *not* necessarily to an underlying `FileIO` (an Iceberg core 
construct). We might already be improperly mixing too much into just the 
open-ended properties map we give to the factory, but IMO we should update the 
`FileIOFactory` interface to:
   
       FileIO loadFileIO(String impl, Map<String, String> properties, 
PolarisResolvedPathWrapper targetEntity);
   
   Maybe in the future even explicitly passing in some form of call context
   
       FileIO loadFileIO(String impl, Map<String, String> properties, 
PolarisResolvedPathWrapper targetEntity, CallContext callContext);
   
   The use case here is for better injectable functionality in the form of the 
`FileIOFactory` for Polaris service-owners where custom logic that might relate 
to custom internalProperties can easily intercept the construction of new 
FileIO instances with all the necessary information about the current request 
available.



-- 
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]

Reply via email to