dennishuo commented on code in PR #270:
URL: https://github.com/apache/polaris/pull/270#discussion_r1746147359
##########
polaris-core/src/main/java/org/apache/polaris/core/PolarisConfiguration.java:
##########
@@ -150,4 +150,21 @@ public static <T> Builder<T> builder() {
"If set to true, allows tables to have external locations
outside the default structure.")
.defaultValue(false)
.build();
+
+ public static final PolarisConfiguration<Boolean> CLEANUP_ON_NAMESPACE_DROP =
+ PolarisConfiguration.<Boolean>builder()
+ .key("CLEANUP_ON_NAMESPACE_DROP")
+ .catalogConfig("cleanup.on.namespace.drop")
+ .description("If set to true, clean up data when a namespace is
dropped")
+ .defaultValue(false)
+ .build();
+
+ public static final PolarisConfiguration<Boolean> DROP_WITH_PURGE_ENABLED =
+ PolarisConfiguration.<Boolean>builder()
+ .key("ALLOW_DROP_WITH_PURGE")
+ .catalogConfig("dropWithPurge.enabled")
Review Comment:
I'm not sure if we have many other examples of camelCase configs yet, but I
recall for some other config keys we wanted to stick to `kebab-case` for
consistency with other Iceberg conventions. So, `drop-with-purge` would be more
in-line
##########
polaris-core/src/main/java/org/apache/polaris/core/persistence/PolarisMetaStoreManagerImpl.java:
##########
@@ -1502,6 +1506,26 @@ public Map<String, String>
deserializeProperties(PolarisCallContext callCtx, Str
}
}
+ // Check that cleanup is enabled, if it is set:
+ if (catalogPath != null && cleanup) {
+ boolean dropWithPurgeEnabled =
+ callCtx
+ .getConfigurationStore()
+ .getConfiguration(
+ callCtx,
+ (CatalogEntity) catalogPath.get(0),
+ PolarisConfiguration.DROP_WITH_PURGE_ENABLED);
+ if (dropWithPurgeEnabled) {
Review Comment:
Looks like this is inverted - should throw exception if
`!dropWithPurgeEnabled`?
I wonder if we should use `BadRequestException` (which is sometimes thrown
for other types of "violated constraints" that aren't necessarily controlled by
RBAC) and reserve `ForbiddenException` for things that pertain to RBAC/grants
--
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]
