feat: schema version promotion#8031
Conversation
🚀 Snapshot Release (
|
| Package | Version | Info |
|---|---|---|
@graphql-hive/cli |
0.60.0-alpha-20260601045530-fa604526b784e75a268b691ca903a3b75e03cab5 |
npm ↗︎ unpkg ↗︎ |
hive |
11.2.0-alpha-20260601045530-fa604526b784e75a268b691ca903a3b75e03cab5 |
npm ↗︎ unpkg ↗︎ |
| ALTER TABLE "schema_versions" | ||
| ALTER COLUMN IF EXISTS "action_id" DROP NOT NULL | ||
| , ADD COLUMN IF NOT EXISTS "origin" jsonb NULL | ||
| , ADD COLUMN IF NOT EXISTS "supergraph_changes" jsonb NULL |
There was a problem hiding this comment.
We store the public schema changes in a separate table schema_version_changes. However, we do not do anything with that table aside from loading the rows. No custom indices etc.
Thus I made the decision to add the column to store supergraph changes to the schema_versions table directly.
If nobody has objections I will refrain from introducing a new table for this.
|
🐋 This PR was built and pushed to the following Docker images: Targets: Platforms: Image Tag: |
There was a problem hiding this comment.
Code Review
This pull request introduces a schema version promotion feature, allowing users to promote a schema version from one target to another within a project. It includes a new database migration, GraphQL schema updates for the schemaVersionPromote mutation and PromotionSchemaLog type, and significant logic in SchemaPublisher and SchemaVersionStore to handle the promotion process and track version origins. Feedback includes identifying a missing crypto import that will cause runtime errors, a typo in a SQL string, and unsafe array access. Additionally, there are suggestions to update an incorrect migration comment, reconsider the use of a dummy field in the GraphQL schema, and evaluate if STITCHING projects should also support this feature.
91ca78a to
05a3f05
Compare
c0f20b4 to
9d6cac5
Compare
| ALTER TABLE "schema_version_to_log" | ||
| ADD COLUMN IF NOT EXISTS type hive_subgraph_log_type DEFAULT NULL | ||
| , ADD COLUMN IF NOT EXISTS "previous_action_id" UUID DEFAULT NULL REFERENCES "schema_log"("id") ON DELETE CASCADE | ||
| , ADD COLUMN IF NOT EXISTS "schema_changes" JSONB DEFAULT NULL | ||
| , ADD COLUMN IF NOT EXISTS "subgraph_name" TEXT NULL | ||
| ; |
There was a problem hiding this comment.
This type stores now more complex information that serves the purpose of tracking how the subgraphs changed between schema versions.
0688fb7 to
7c4350f
Compare
There was a problem hiding this comment.
Updated integration tests to use SchemaVersion.meta and SchemaVersion.origin instead of the deprecated field SchemaVersion.log
| message = 'Expected non-null value.', | ||
| ): asserts value is T { | ||
| if (value === null) { | ||
| if (value == null) { |
There was a problem hiding this comment.
this helper was not doing what it should do 😆
There was a problem hiding this comment.
Updated to use the fields that are not deprecated.
There was a problem hiding this comment.
A bunch of tests tor the new schema version promote functionality
There was a problem hiding this comment.
New CLI command for promotion a schema version.
a3681e8 to
fd280ee
Compare
ab1d72b to
1f340b8
Compare
Description
Introduces functionality for promoting a schema version from one target to another target (or the same target), making it the latest version within that target.
This enables workflows such as:
What should be reviewed?
For either of those feel free to hit me up if you want to walk me through things.
CLI
A new CLI command
schema:promoteis introduced for promoting schema VersionPermissions
A new permission
schemaVersion:promoteis introduced to restrict to which targets a schema version can be promoted.New History UI
Alongside a new CLI command for performing these promotions this change also comes along a new UI for schema versions with more insights into the individual changes of the subgraphs.
More UI Screenshots
Database
The database was altered with new columns for storing the new data that is collected for subgraphs.
Refer to the migration file for a breakdown of all new introduced columns.
The database schema is fully backwards compatible. If any major issues occur on the business logic of the API, we can easily roll it back as all the changes introduced are additional.
GraphQL API
Other
Closes #4021