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


##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalog.java:
##########
@@ -1083,6 +1093,74 @@ private void validateNoLocationOverlap(
     }
   }
 
+  /** Checks whether the location of a namespace is valid given its parent */
+  private void validateNamespaceLocation(
+      NamespaceEntity namespace, PolarisResolvedPathWrapper resolvedParent) {
+    StorageLocation namespaceLocation =
+        StorageLocation.of(
+            StorageLocation.ensureTrailingSlash(
+                resolveNamespaceLocation(namespace.asNamespace(), 
namespace.getPropertiesAsMap())));
+    PolarisEntity parent = resolvedParent.getResolvedLeafEntity().getEntity();
+    if (parent.getType().equals(PolarisEntityType.CATALOG)) {
+      CatalogEntity parentEntity = CatalogEntity.of(parent);
+      LOGGER.debug(
+          "Validating namespace {} given parent catalog {}",
+          namespace.getName(),
+          parentEntity.getName());
+      var storageConfigInfo = parentEntity.getStorageConfigurationInfo();
+      if (storageConfigInfo == null) {
+        throw new IllegalArgumentException(
+            "Cannot create namespace without a parent storage configuration");
+      }
+      boolean allowed =
+          
parentEntity.getStorageConfigurationInfo().getAllowedLocations().stream()

Review Comment:
   AllowedLocations in the StorageConfig are an independent concept vs either 
of:
   
   1. Whether to allow "custom" locations outside of the default path hierarchy 
that uses namespace names
   2. Whether to allow "overlapping" locations
   
   The most important one is validating that anything that can vend credentials 
resides under the allowedLocations.
   
   Overlap and custom hierarchies in general are more common to disable 
validation for.



-- 
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: issues-unsubscr...@polaris.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to