-
Notifications
You must be signed in to change notification settings - Fork 42
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Refactor Handling of Name<->ID Mapping in OpenAPI Generator (#547)
## Changes This PR proposes a refactor to the x-databricks-id and x-databricks-name extensions to the OpenAPI specification to support schema reuse while still providing the name <-> ID mapping features. Many resources in Databricks have user-facing names (like job name, cluster name, etc.). However, for many API calls, this name cannot be used to identify the resource; instead, a system-generated resource ID must be used instead (like job ID, cluster ID, etc.). For resources that support listing, the presence of these two extensions in the response body triggers the generation of additional code in the SDKs as convenience features for interacting with these resources, namely: * GetByName methods that allow looking up a resource by its user-facing name, and * XToYMap methods that materialize a mapping from name to resource. Previously, these extensions were defined at the level of a schema, where a field within a schema marked with these extensions would be a candidate for the above functionality. However, there is a problem with this when a component is reused in multiple APIs. First, it is possible to define a single field as a component. This is useful if the field is present in different related resources but the documentation/type of the field should be consistent. Beyond this, it is possible for a list response to contain multiple fields corresponding to IDs to Databricks resources, but in this scenario, only one of those IDs is actually the ID of the underlying resource. If the response body contains two or more fields marked with x-databricks-id or x-databricks-name, it is impossible for our code generator to know which was intended as the ID/Name for the resource. Furthermore, there are instances where these extensions are not used correctly: users would annotate path parameters with these extensions, but these only make sense in the context of a list response. Ultimately, the fields used for name and ID are specific to the operation itself and not to the schema. This allows multiple ID/name fields to be reused as components within a listing response, and the definition of which to use for name-to-ID mapping is fixed at the operation level. This way, different operations can define different fields to use for this mapping. This PR implements this change by moving the name & ID fields from the Schema level to the Operation level. The type of this extension changes from a boolean to a list of strings, corresponding to the path of fields to be traversed to get to the respective field in the response entity. The starting point for this traversal is the underlying resource itself, as opposed to the response body. Additionally, it adds support for nested ID fields (by preserving the implementation between the treatment of name and ID). Unfortunately, it also updates the Go SDK to a relatively recently OpenAPI commit as well, so there are additional changes here. Next steps: - [ ] Update OpenAPI spec in Universe, refactoring these extensions to the Operation level. - [ ] Update Go SDK with this change. - [ ] Update Python SDK with this change. - [ ] Update Java SDK with this change. - [ ] Update go/openapi/spec with this change. ## Tests <!-- How is this tested? Please see the checklist below and also describe any other relevant tests --> - [ ] `make test` passing - [ ] `make fmt` applied - [ ] relevant integration tests applied
- Loading branch information
Showing
27 changed files
with
926 additions
and
203 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.