Describe the bug
Updating default-base-location without also updating storageConfigInfo appears to leave the catalog in an inconsistent state.
The catalog property is changed, but the persisted allowedLocations can still reflect only the old base location. After that, namespace creation, table creation, or location validation may fail although the catalog update itself was accepted.
For example:
- Initial state:
default-base-location = s3://foo/, allowedLocations = ["s3://foo/"]
- Use the Polaris CLI to only update the
default-base-location to s3://bar/
- Namespace creations and potentially table creations appear to fail
In my opinion, Polaris should reject such an update if the effective storage configuration does not allow the new default-base-location.
An alternative approach might be to automatically add a new default-base-location to allowedLocations. This alternative however feels a bit too risky to me.
To Reproduce
No response
Actual Behavior
No response
Expected Behavior
No response
Additional context
No response
System information
No response
Describe the bug
Updating
default-base-locationwithout also updatingstorageConfigInfoappears to leave the catalog in an inconsistent state.The catalog property is changed, but the persisted
allowedLocationscan still reflect only the old base location. After that, namespace creation, table creation, or location validation may fail although the catalog update itself was accepted.For example:
default-base-location=s3://foo/,allowedLocations=["s3://foo/"]default-base-locationtos3://bar/In my opinion, Polaris should reject such an update if the effective storage configuration does not allow the new
default-base-location.An alternative approach might be to automatically add a new
default-base-locationtoallowedLocations. This alternative however feels a bit too risky to me.To Reproduce
No response
Actual Behavior
No response
Expected Behavior
No response
Additional context
No response
System information
No response