You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@polaris.apache.org by "ayushtkn (via GitHub)" <gi...@apache.org> on 2026/08/31 23:00:48 UTC
[PR] Skip the default-location check when the namespace location was not requested [polaris]
ayushtkn opened a new pull request, #5422:
URL: https://github.com/apache/polaris/pull/5422
`createNamespaceInternal` validates the namespace location against the default derived from its parent even when the request specified no location. In that case the location being checked is the one Polaris just derived: `setBaseLocation` stores it in the entity's properties, so the validator reads that value back and compares it against the same derivation, and it can only pass. `setProperties` already guards the same call on whether the request carried a location, so this makes create consistent with it.
No behaviour change. Added tests for sanity which covers the four location cases - no location, the default stated explicitly, a different location, and a different location with `ALLOW_NAMESPACE_CUSTOM_LOCATION` enabled - and passes with and without the guard.
This fixes the follow-up suggestion along with test covering all the 4 cases from @flyrain here: https://github.com/apache/polaris/pull/5357#issuecomment-5481307673
## Checklist
- [ ] 🛡️ Don't disclose security issues! (contact security@apache.org)
- [ ] đź”— Clearly explained why the changes are needed, or linked related issues: Fixes #
- [ ] đź§Ş Added/updated tests with good coverage, or manually tested (and explained how)
- [ ] đź’ˇ Added comments for complex logic
- [ ] đź§ľ Updated `CHANGELOG.md` (if needed)
- [ ] 📚 Updated documentation in `site/content/in-dev/unreleased` (if 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: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3899192669
##########
runtime/service/src/test/java/org/apache/polaris/service/catalog/iceberg/IcebergAllowedLocationTest.java:
##########
@@ -730,6 +730,67 @@ void testCreateNamespaceWhenBaseLocationIsNestedInsideAllowedLocation(@TempDir P
.hasMessageContaining("has a custom location");
}
+ /**
+ * The four namespace-location cases, with ALLOW_NAMESPACE_CUSTOM_LOCATION off for the first three
+ * and on for the last.
+ */
+ @Test
+ void testNamespaceCustomLocationRules(@TempDir Path tmpDir) {
+ Map<String, Object> baseConfig =
+ Map.of(
+ "ALLOW_INSECURE_STORAGE_TYPES",
+ "true",
+ "SUPPORTED_CATALOG_STORAGE_TYPES",
+ List.of("FILE"));
+ String catalogLocation = tmpDir.toAbsolutePath().toUri().toString();
+
+ TestServices strict = TestServices.builder().config(baseConfig).build();
+ createCatalog(strict, Map.of(), catalogLocation, List.of(catalogLocation));
+ String defaultBase = String.format("%s/%s", catalogLocation, catalog);
+
+ // 1. No location requested: the default is derived and used.
+ assertThat(createNamespaceStatus(strict, "ns1", null))
+ .isEqualTo(Response.Status.OK.getStatusCode());
+
+ // 2. The default location, stated explicitly: allowed, it is explicit but not custom.
+ assertThat(createNamespaceStatus(strict, "ns2", defaultBase + "/ns2"))
+ .isEqualTo(Response.Status.OK.getStatusCode());
+
+ // 3. A location other than the default: rejected as custom.
+ assertThatThrownBy(() -> createNamespaceStatus(strict, "ns3", catalogLocation + "/elsewhere"))
+ .isInstanceOf(IllegalArgumentException.class)
+ .hasMessageContaining("has a custom location");
Review Comment:
`Path.toUri().toString()` for a directory ends with a trailing `/`, so `catalogLocation + "/elsewhere"` will produce a double-slash path (`...//elsewhere`). That makes the test data less clear and can interact with location normalization. Consider using the same concatenation style as the earlier test in this file (`base + "elsewhere"`).
This issue also appears on line 768 of the same file.
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "flyrain (via GitHub)" <gi...@apache.org>.
flyrain merged PR #5422:
URL: https://github.com/apache/polaris/pull/5422
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "flyrain (via GitHub)" <gi...@apache.org>.
flyrain commented on PR #5422:
URL: https://github.com/apache/polaris/pull/5422#issuecomment-5516908902
Will merge it by EOD if there is no further comments.
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "dimas-b (via GitHub)" <gi...@apache.org>.
dimas-b commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3905113593
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
> validateNamespaceUsesDefaultLocation() doesn’t validate allowed catalog locations.
Indeed, I was probably tired and confused during my review :facepalm:
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "dimas-b (via GitHub)" <gi...@apache.org>.
dimas-b commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3905196651
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
Re: steps 1,2,3 above: this is exactly what I find confusing :) We first derive the namespace location from some data, then try to decided whether the location was provided by the user or chosen by polaris in another place.
Why not validate when we decide to use the user-provided location?.. that is inside `resolveNamespaceLocation()`? :thinking:
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "dimas-b (via GitHub)" <gi...@apache.org>.
dimas-b commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3900199927
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
This logic looks very confusing to me 🤔 The condition for validation is based on `metadata`, but `validateNamespaceUsesDefaultLocation()` operates on the `entity`, not on `metadata`... it is very obscure why we should only run validation if the base location key is present in `metadata` 🤔
Does it hurt to validate unconditionally?
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "ayushtkn (via GitHub)" <gi...@apache.org>.
ayushtkn commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3900389069
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
Thanx @dimas-b for the review
> is logic looks very confusing to me 🤔 The condition for validation is based on metadata, but validateNamespaceUsesDefaultLocation() operates on the entity, not on metadata... it is very obscure why we should only run validation if the base location key is present in metadata 🤔
The guard is really about caller intent, not about what ends up on the entity:
1. If the request omits location, resolveNamespaceLocation() derives the default from the parent.
2. `setBaseLocation()` always writes that value onto the entity (via properties), so the entity always has a base location after build.
https://github.com/apache/polaris/blob/e0a4306933b563584892ba98cb6c454b5ac1b77b/polaris-core/src/main/java/org/apache/polaris/core/entity/NamespaceEntity.java#L84-L86
3. `validateNamespaceUsesDefaultLocation()` re-derives the same default and compares it to the entity’s location.
When the caller did not supply a location, step 3 compares the derived value against itself — it can only pass.
So: “did the caller explicitly provide a location?” — not “does the entity have one?” (it always will after `setBaseLocation`).
> Does it hurt to validate unconditionally?
Functionally it should still pass for derived locations. But it reads like we’re enforcing something meaningful when we’re not. The guard makes the intent explicit: when `ALLOW_NAMESPACE_CUSTOM_LOCATION` is `off`, reject only caller-supplied custom locations.
> Also, validateNamespaceUsesDefaultLocation() validates the "allowed" locations, which probably makes sense to do even if the namespace's own location is derived from its name (by Polaris)
`validateNamespaceUsesDefaultLocation()` doesn’t validate allowed catalog locations. It only checks that the namespace location exactly equals the default Polaris derives from the parent (`resolveLocationForPath(parent) + "/" + namespaceName`, with trailing-slash normalization via `StorageLocation`).
https://github.com/apache/polaris/blob/e0a4306933b563584892ba98cb6c454b5ac1b77b/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java#L1442-L1443
Allowed-location enforcement for namespaces happens elsewhere (e.g. at table create time via `validateLocationForTableLike`). Namespace create doesn’t run that check today — with or without this guard. You can see that in `IcebergAllowedLocationTest.testCreateTableOutSideOfCatalogAllowedLocations`, where a namespace is created outside allowed locations and the failure only shows up at table create.
So when Polaris derives the location itself, this validator adds no independent check — it’s the same derivation compared against itself. Skipping it for the “no location requested” case doesn’t weaken allowed-location policy; it just avoids a no-op and matches what `setProperties` already does here
https://github.com/apache/polaris/blob/e0a4306933b563584892ba98cb6c454b5ac1b77b/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java#L901-L902
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "dimas-b (via GitHub)" <gi...@apache.org>.
dimas-b commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3905259855
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
Sorry for the trouble... I'm just trying to make the overall code easier to reason about :)
After a more careful review, current changes look valid to me. Please treat this as an optional suggestion.
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Skip the default-location check when the namespace location was not requested [polaris]
Posted by "dimas-b (via GitHub)" <gi...@apache.org>.
dimas-b commented on code in PR #5422:
URL: https://github.com/apache/polaris/pull/5422#discussion_r3900235296
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -702,7 +702,9 @@ private void createNamespaceInternal(
}
if (!realmConfig.getConfig(
BehaviorChangeConfiguration.ALLOW_NAMESPACE_CUSTOM_LOCATION, catalogEntity)) {
- validateNamespaceUsesDefaultLocation(entity, resolvedParent);
+ if (metadata.containsKey(PolarisEntityConstants.ENTITY_BASE_LOCATION)) {
+ validateNamespaceUsesDefaultLocation(entity, resolvedParent);
Review Comment:
Also, `validateNamespaceUsesDefaultLocation()` validates the "allowed" locations, which probably makes sense to do even if the namespace's own location is derived from its name (by Polaris) 🤔
--
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-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org