Manage Schema Versioning
All changes to configuration are subject to versioning. Version numbers are incremental integers. Version changes are handled using the following rules:
- If a version number is not supplied to a configuration query, Skylark will generate a new version based on the current active configuration version.
- Prior to becoming active, any number of changes can be made to a version by supplying the version number to the configuration queries.
- Once a version is activated, it can no longer be changed, and you'll need to make schema changes in a new version.
- Supplying an activated version number to a configuration query will generated a new version based on the version number supplied. See below for examples.
- If a version number that doesn't exist is supplied, a new version will be generated using an incremental version number based on the current active version.
Activate Version
Once you're happy with a draft version you can make it live by using the activateConfigurationVersion
mutation and supply the version to activate.
mutation {
activateConfigurationVersion(version: 2) {
messages
}
}
Update Existing Versions
If you have a draft version in progress you want to make more changes to, supply the version number of that draft to configuration request.
mutation EditFields {
editFieldConfiguration(
version: 2,
fields: {
type: STRING,
operation: CREATE,
name: "testing"
}, object_class: "Episode",
) {
version
messages
}
}
Response:
{
"data": {
"editFieldConfiguration": {
"version": 2,
"messages": [
"Updated draft version 2",
"Adding field testing to Episode"
]
}
}
}
Create New Version
There are a number of different ways to create new versions.
Not supplying version
to a configuration query.
version
to a configuration query.In this example no version argument is supplied so a new version is created based on the current active version.
mutation EditFields {
editFieldConfiguration(
fields: {
type: STRING,
operation: CREATE,
name: "testing"
}, object_class: "Episode",
) {
version
messages
}
}
Response:
{
"data": {
"editFieldConfiguration": {
"version": 2,
"messages": [
"Creating new version (2) from active version",
"Adding field testing to Episode"
]
}
}
}
Supplying a version
to a configuration query that has already been activated.
version
to a configuration query that has already been activated.In this example a version number has been supplied to the configuration mutation, however that version has already been activated. The outcome is that a new version is created using the version number supplied as the base.
mutation EditFields {
editFieldConfiguration(
version: 1,
fields: {
type: STRING,
operation: CREATE,
name: "testing"
}, object_class: "Episode",
) {
version
messages
}
}
Response:
{
"data": {
"editFieldConfiguration": {
"version": 2,
"messages": [
"Version 1 has already been activated. Creating a new version (2) based on it.",
"Adding field testing to Episode"
]
}
}
}
Supplying a version
to a configuration query that doesn't exist
version
to a configuration query that doesn't existIn this example a version argument is supplied but that version does not exist so a new version is created based on the current active version.
mutation EditFields {
editFieldConfiguration(
version: 100,
fields: {
type: STRING,
operation: CREATE,
name: "testing"
}, object_class: "Episode",
) {
version
messages
}
}
Response:
{
"data": {
"editFieldConfiguration": {
"version": 2,
"messages": [
"Version 100 not found. Creating new version (2) based on active version.",
"Adding field testing to Episode"
]
}
}
}
Check For Active Schema Version
You can use the below query to find out which schema version is currently active:
query ActivationStatus {
getActivationStatus {
active_version
}
}
Sample Response:
{
"data": {
"getActivationStatus": {
"active_version": "2"
}
}
}
Updated 7 months ago