-
Notifications
You must be signed in to change notification settings - Fork 332
Unblock test createViewWithCustomMetadataLocation
#1320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unblock test createViewWithCustomMetadataLocation
#1320
Conversation
createViewWithCustomMetadataLocation
cd7ea05 to
887e001
Compare
887e001 to
0dc0fec
Compare
dimas-b
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for bringing this up @liamzwbao !
Test code changes LGTM. However, I believe the issues mentioned in the description probably need to be discussed on the dev mailing list rather than in GH. Could you start a discussion thread there?
| String customLocationChild = | ||
| Paths.get(tempDir.toUri().toString(), "custom-location/child").toString(); | ||
|
|
||
| if (requiresNamespaceCreate()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this not always true in Polaris?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is copied from the test in Iceberg and it's unnecessary here, let me remove this check.
| super.createViewWithCustomMetadataLocation(); | ||
| Assertions.assertThatThrownBy(super::createViewWithCustomMetadataLocation) | ||
| .isInstanceOf(ForbiddenException.class) | ||
| .hasMessageContaining("Forbidden: Invalid locations"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change and the following test method LGTM because they assert existing Polaris behaviour.
* Fix regression test docker setup for purge (apache#1768) * Use canonical catalog property names in tests (apache#1766) * In `PolarisPolicyServiceIntegrationTest` * In `PolarisRestCatalogIntegrationTest` Following up to apache#1557 * Unblock test `createViewWithCustomMetadataLocation` (apache#1320) * Add test for invalid custom metadata location * Add missing properties during table/view creation * main: Update docker.io/prom/prometheus Docker tag to v3.4.1 (apache#1767) * Testing: silence a bunch of harmless test warnings (apache#1773) * `OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended` * Hibernate Validator cannot instrument static methods (`Hibernate Validator does not support constraints on static methods yet. ...`) * ForkJoinPool test lifecycle warning * Couple of split-package warnings * Add unit test for legacy config lookup (apache#1774) Following up on apache#1766 * Handle RequestScoped instance injection gracefully for DefaultConfigurationStore (apache#1758) Although we do a check of !realmContextInstance.isUnsatisfied() it only checks if there is matching bean, however, it doesn't check if the context is active or not. Similarly isResolvable also don't check if the scope is active. Therefore if getConfiguration is called when there is no active scope, it will get Exception like ContextNotActiveException. This actually fails the TaskExecutor because it runs in a separate thread. In order to fix the problem, we introduces a new getConfiguration function to handle the background tasks, and also use isResolvable instead of isUnsatisfied to handle ambiguities. * Restructure the directory and package name for persistence modules (apache#1724) * Re-add missing parameters to create_table python API (apache#1778) It looks like this method lost the `prefix` and `namespace` parameters in apache#1347. They're re-introduced to the spec here, and then I've run: ``` redocly bundle spec/polaris-catalog-service.yaml -o spec/generated/bundled-polaris-catalog-service.yaml ./gradlew regeneratePythonClient ``` Then, some manual reverts: ``` alias gitrevert='git checkout upstream/main --' gitrevert client/python/.github/workflows/python.yml gitrevert client/python/.gitlab-ci.yml gitrevert client/python/pyproject.toml ``` I still hope to automate this process as part of CI soon; see apache#1675 * Replace getConfiguration usage with PolarisCallContext to use RealmContext (PART 1) (apache#1780) * JDBC: Fix getting started config (apache#1781) Fix typo in the JDBC config for getting started, the config should be max_duration_in_ms instead of max_delay_in_ms * main: Pin dependencies (apache#1701) * main: Update dependency pytest to v8 (apache#1710) * main: Update dependency boto3 to v1.38.28 (apache#1777) * Run renovatebot only on the main branch (apache#1786) * INFO: last merged commit a827d26 --------- Co-authored-by: gh-yzou <[email protected]> Co-authored-by: Dmitri Bourlatchkov <[email protected]> Co-authored-by: Liam Bao <[email protected]> Co-authored-by: Mend Renovate <[email protected]> Co-authored-by: Yufei Gu <[email protected]> Co-authored-by: Eric Maynard <[email protected]> Co-authored-by: Prashant Singh <[email protected]> Co-authored-by: JB Onofré <[email protected]>
Summary
Fix #1273
Currently, Polaris does not allow creating a view with a
customMetadataLocationoutside of theallowedLocationsdefined in thestorageConfig, but I think this might be a feature we need to unblock. I've documented Polaris's behavior in this PR and would appreciate the ideas of what should be the expected behavior. Here's a summary:1. View Creation with Custom Metadata Location
A user cannot create a view with a
customMetadataLocationoutside ofallowedLocationsinstorageConfig, unless:write.metadata.path.customMetadataLocationis 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 atfile://baseLocation/customLocation.2. Editing View’s Metadata Location to a Sibling Path
Once the view is created, the user cannot update its
customMetadataLocationto a sibling path likefile://baseLocation/customLocation2Reason:
The validation logic currently checks against the view’s own
write.metadata.pathfor 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/childReason:
This is rejected because the view’s properties are stored in
internalPropertiesrather thanproperties, so the previous config override becomes ineffective.Questions
write.metadata.pathfeature?