tools/importer-rest-api-specs: refactoring the Parser package
#4307
Conversation
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
…ers out into the new structure
…a Data Workaround
…e over to using the SDK types/new path This is a copy and patch up, since I want to leave the existing code path as-is for the moment, to break it apart more effectively
… Service/APIVersion
…rkarounds` package
…age into the new structure
…to the new package This wants refactoring, but moving it over allows cleaning the rest up
…kage There's a bunch of these, and whilst these'll get replaced in time with #4017 but for now this cleans this up
…w package The `parser` package itself needs cleaning, but there's a few things to do first
The rebase is messed up, but it's a minor patch so should be fine
…packages This leaves the old parser logic in place for now, which'll be cleaned up in the next commit
… command didn't pass the API Definitions Directory correctly
…ch ensures that when we compare the ObjectDefinition from a previously parsed/currently parsed dataset we have matching values These are normalised post-parsing, so when comparing against the old data set we need to use TitleCase too, so we might as well do this here
…to build the api resource name
…tests These ensure that the Configs can be parsed and that the Data from them can be loaded
… data test @manicminer is going to work through fixing this one up, this requires parsing the data identifying any parent types and patching any disciminated implementations across
tombuildsstuff
changed the title
tools/importer-rest-api-specs: refactoring the Parser package
…since it doesn't seem to be required for DataFactory models as they use external Swagger Refs.
…licates (avoid parsing the same tag twice)
manicminer
added
tool/importer-rest-api-specs
This reverts commit 31b45ca.
stephybun
approved these changes
Jul 31, 2024
|
|
||
| Where possible we use the terminology `API Definition` since these are implementation details - but this more specific terminology will be used where necessary. | ||
|
|
||
| TODO also mention Supplemental Data |
There was a problem hiding this comment.
@manicminer do you have context on this?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors the Parser package into
apidefinitions- and removes the old logic/pipelineRight now this mostly works and requires a few fixes around Discriminators/Supplementary Data that @manicminer is going to pick up
Mostly fixes/rounds out #3754