Skip to content
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

Treat missing default-base-location in UpdateCatalogRequest as no-change to default-base-location #440

Conversation

dennishuo
Copy link
Contributor

@dennishuo dennishuo commented Nov 7, 2024

The way the API model for Catalogs splits out the default-base-location as a required field separate from "additionalProperties" makes it easy for client libraries to forget to forget to "echo" an existing default-base-location when trying to set new properties.

Since the default-base-location is required during catalog creation, it definitely wasn't correct to allow silently clobbering it in an update. So the only possibilities are:

  1. Throw explicit error if it's missing
  2. Treat it the same as when an UpdateCatalogRequest doesn't specify a StorageConfigInfo, which is to assume that the unspecified portion of the request should be unaltered

Given the structure of the API making it easy to miss this fact, I'd say the most correct semantic here is to treat the same as unspecified StorageConfigInfo, and just leave default-base-location unchanged if it's missing from the UpdateCatalogRequest.

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Test A
  • Test B

Test Configuration:

  • Hardware:
  • Toolchain:
  • SDK:

Checklist:

Please delete options that are not relevant.

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • If adding new functionality, I have discussed my implementation with the community using the linked GitHub issue

…nge to default-base-location

The way the API model for Catalogs splits out the default-base-location as a required field
separate from "additionalProperties" makes it easy for client libraries to forget to
forget to "echo" an existing default-base-location when trying to set new properties.

Since the default-base-location is required during catalog creation, it definitely wasn't
correct to allow silently clobbering it in an update. So the only possibilities are:

1. Throw explicit error if it's missing
2. Treat it the same as when an UpdateCatalogRequest doesn't specify a StorageConfigInfo,
  which is to assume that the unspecified portion of the request should be unaltered

Given the structure of the API making it easy to miss this fact, I'd say the most correct
semantic here is to treat the same as unspecified StorageConfigInfo, and just leave
default-base-location unchanged if it's missing from the UpdateCatalogRequest.
Copy link
Contributor

@collado-mike collado-mike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was definitely the original intention that if something was omitted during an update, that meant to leave it unchanged.

@collado-mike collado-mike enabled auto-merge (squash) November 8, 2024 16:52
@eric-maynard
Copy link
Contributor

With this change, it looks like calls to updateCatalog won't overwrite properties that aren't specified in the request. This behavior makes sense to me, but can you add a short blurb to the spec clarifying this?

@sfc-gh-dhuo
Copy link

With this change, it looks like calls to updateCatalog won't overwrite properties that aren't specified in the request. This behavior makes sense to me, but can you add a short blurb to the spec clarifying this?

Done.

…as-noop' of github.com:dennishuo/polaris into dhuo-handle-no-default-base-location-in-update-catalog-as-noop
@eric-maynard eric-maynard enabled auto-merge (squash) November 8, 2024 23:03
@eric-maynard eric-maynard merged commit 753f453 into apache:main Nov 8, 2024
5 checks passed
@jbonofre
Copy link
Member

jbonofre commented Nov 9, 2024

Sorry, I'm late on this PR.

Even if it can be seen as a breaking change, I think it makes sense to do it because the catalog could be in a inconsistent state.
So, I agree with the PR.

Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants