Unblock test createViewWithCustomMetadataLocation

[liamzwbao]

Describe the bug

The test createViewWithCustomMetadataLocation in PolarisRestCatalogViewIntegrationBase is disabled in #1126 as the expected behavior is not applicable to Polaris.

To unblock, update this to expect an exception and add a Polaris-specific test.

To Reproduce

Remove the @Disabled annotation and run the test.

Actual Behavior

The test fails as the custom metadata location write.metadata.path is outside of the configured allowedLocations.

Expected Behavior

This test is expected to fail in Polaris. Need to add a separate test that verifies the correct usage of write.metadata.path within Polaris.

Additional context

No response

System information

No response

[liamzwbao]

Hi team, the test mentioned in this issue does not reflect Polaris's actual behavior — Polaris does not allow creating a view with a customMetadataLocation outside of the allowedLocations defined in the storageConfig. I've documented Polaris's behavior in PR #1320. Here's a summary:

1. View Creation with Custom Metadata Location

A user cannot create a view with a customMetadataLocation outside of allowedLocations in storageConfig, unless:

• The parent namespace defines the property write.metadata.path.
• The customMetadataLocation is a subpath of that value.

This behavior is enabled by this code block, which updates the storage config to include write.metadata.path.

Example:
If the namespace has write.metadata.path=file://baseLocation, then the view can be created at file://baseLocation/customLocation.

2. Editing View’s Metadata Location to a Sibling Path

Once the view is created, the user cannot update its customMetadataLocation to a sibling path like file://baseLocation/customLocation2

Reason:
The validation logic currently checks against the view’s own write.metadata.path for updating, not the parent namespace’s.

3. Editing Metadata Location to a Subpath Also Fails

Even updating the metadata location to a child path of the original is not allowed: file://baseLocation/customLocation → file://baseLocation/customLocation/child

Reason:
This is rejected because the view’s properties are stored in internalProperties rather than properties, so the previous config override becomes ineffective.

Questions

• What is the intended behavior for this write.metadata.path feature?
• The config override logic mentioned above doesn't appear to be covered by any existing tests. I'm wondering the purpose of it.

[liamzwbao]

cc @collado-mike @eric-maynard @RussellSpitzer for more context. Please take a look when you got a chance, thank you!