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

tools/data-api-repository: consolidating the reading/writing of data into data-api-repository / updated support for Common Types #4217

Merged
merged 28 commits into from
Jun 21, 2024

Conversation

tombuildsstuff
Copy link
Contributor

@tombuildsstuff tombuildsstuff commented Jun 20, 2024

This PR consolidates the Reading and Writing of data into tools/data-api-repository - meaning that this becomes the single source-of-truth for where data is loaded/persisted from disk.

This PR also:

  • Consolidates the transforms and types from tools/data-api into tools/data-api-repository
  • Refactors tools/data-api to use this new repository
  • Refactors tools/importer-rest-api-specs to use the new PurgeExistingData method (which I’ve incorporated from tools/importer-msgraph-metadata: refactor to generate JSON definitions using data-api-sdk #4167)
  • Fixes a couple of bugs in tools/importer-rest-api-specs and tools/data-api-repository where APIResources containing Constants and Models with no Operations (and thus weren’t usable) were being output - but not included in the list of APIResources for an APIVersion. As a result of this change, in the next generation, a handful of unused types will be removed.
  • Fixed the value for sourceInformation within ./api-definitions/handwritten-resource-manager so this parses correctly
  • Added support for loading/saving Common Types - and updated the Data API & Data API SDK accordingly. This means that we have a set of Common Types per API Version, so if a Data Source Type opts to use Common Types, these can be used as needed - however additional work is needed to enable these which is ultimately tracked in [WIP] Common Types #4214.
  • Notably, when multiple Data Source Origins for the same Data Source Type support Common Types, these are merged together (in the same way that Services are) - meaning that we can add Handwritten overrides (including Discriminated Implementations) to Imported Data if desired.
  • Moves the Repository-specific Models, Transforms and helper functions into an internal package, so that these remain scoped to this package.
  • Removes the old aliases/helper functions used in the Data API SDK, and fixes a handful of usages - meaning that these are now unused.
  • Fixes a data issue in the handwritten data (AADB2C/2021-04-01-preview/Tenants/Model-UpdateTenantProperties.json) where the UpdateTenantProperties model was unintentionally named TenantProperties, meaning that this could get overwritten when loading the data (and the fields removed).

Notably this PR does not:

  1. Rename the Models used within the data-api-repository package to align with Meta: refactoring #3754. Whilst that will be done, this is intentionally being done in the next stage, since it’s an internal refactor and not changing the public surface area.
  2. Fully enable Common Types - since there’s remaining components for this which are being tracked in [WIP] Common Types #4214 (where more details will be added shortly).

Ultimately this PR unblocks #4167

Pedantic, but enables us to support `serve-watch` in the future/have these defined once for the tool
… take the SourceDataType

Each `Repository` instance is tied to a SourceDataType, therefore we'll need one for Resource Manager and one for Microsoft Graph
within the Data API - however the Importers can each use a single instance.
…I Version.

Whilst this information is stored alongside these as the key to the associated value; it's useful to
have this information stored alongside, too.
This conflicts with `TenantProperties`
…dels with no Operations

In the event there's only Constants and Models these aren't usable, so we may as well skip these?
This both consolidates the logic from `./tools/data-api/internal/repository` (and `./tools/data-api/internal/endpoints/transforms`)
as well as refactors more of the logic into the `internal` package, with the intention to only expose the public surface area and
not the types used for direct access on-disk.
…dding `Name` and `APIVersion` to Service and APIVersion respectively
…values (since this is currently mixed)

Matches the others
…common-types` and ensuring it's not loaded as a Service
… are stored, so that each Stage is more specific to a Service
…sdk`: changing Common Types to be tied to an API Version

Chatting with @manicminer we want this tied to an API Version (for example `V1` and `Beta` for MSGraph), so this commit changes
the endpoints and loads that data from disk in a directory named `common-types`
@tombuildsstuff tombuildsstuff added tool/data-api Issues with the Data API refactor tools/internal-repository This issue/PR is related to `data-api-repository`, used to load/save data labels Jun 20, 2024
@tombuildsstuff tombuildsstuff mentioned this pull request Jun 20, 2024
11 tasks
Copy link
Contributor

@manicminer manicminer left a comment

Choose a reason for hiding this comment

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

Thanks @tombuildsstuff! Just a couple minor comments but this otherwise looks good 👍

tools/data-api-differ/internal/dataapi/data_api_cmd.go Outdated Show resolved Hide resolved
@tombuildsstuff tombuildsstuff merged commit 0974992 into main Jun 21, 2024
4 of 5 checks passed
@tombuildsstuff tombuildsstuff deleted the refactor/data-api-to-use-repository branch June 21, 2024 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor tool/data-api Issues with the Data API tools/internal-repository This issue/PR is related to `data-api-repository`, used to load/save data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants