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

[dennishuo]

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.

• [x] 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.

• [x] 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

[eric-maynard]

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]

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.

[jbonofre]

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 !