AndrewF
AndrewF
XXata
Created by Michael Schaufelberger on 9/3/2024 in #help
What is good practice with Xata's (Multi-version Schema) Migrations?
We don't yet have the full story around iterating on a migration on a branch and then applying a final version to main. We're aiming to build a feature that would allow arbitrary migrations to run on a branch, and then be 'squashed' into one on merge but we don't have today. As things stand the best approach would be either: * take a single branch from main, and experiment with migrations on that branch by applying and undoing[1] migrations. * take multiple branches from main and experiment with migrations, throwing away the branch and starting another until you are happy with the final sequence of migrations on the branch. Once you are happy with the sequence of migrations on the branch, manually apply them to the main branch using the Migration Editor in the UI. If there are multiple migrations they can either be applied as separate migrations, or combined into one migration containing several operations, like this one that contains two add-column operations:
[
{
"add_column": {
"table": "items",
"column": {
"pk": false,
"name": "name",
"type": "text",
"unique": false,
"comment": "",
"nullable": true
}
}
},
{
"add_column": {
"table": "items",
"column": {
"pk": false,
"name": "age",
"type": "int",
"unique": false,
"comment": "",
"nullable": true
}
}
}
]
[
{
"add_column": {
"table": "items",
"column": {
"pk": false,
"name": "name",
"type": "text",
"unique": false,
"comment": "",
"nullable": true
}
}
},
{
"add_column": {
"table": "items",
"column": {
"pk": false,
"name": "age",
"type": "int",
"unique": false,
"comment": "",
"nullable": true
}
}
}
]
[1] 'undoing' a migration can be achieved by either leaving the migration in a 'started' but not 'completed' state and then rolling it back, or by completing it and then writing another migration that undoes the effects of the first.
4 replies
XXata
Created by Michael Schaufelberger on 9/3/2024 in #help
What is good practice with Xata's (Multi-version Schema) Migrations?
With "normal" Xata migrations, every single schema change is a migration and results in its own file. This is suboptimal DX since during development you may have to add a field, rename it and delete it again until you have found the best schema for a feature and have many files in the end that are difficult to review.
This is typically best avoided, regardless of which migration tool you are using. A better workflow would be to make the schema changes on a development branch where migrations can be edited and applied multiple times until the migration is correct. What is then reviewed and merged into main is the final form of the migration, after the experimentation is complete. The same approach applies to using Xata multi-version migrations; make the schema changes on a branch where it's safe to experiment and then apply a final migration to main when you're happy with the migration. The 'multi-version' feature of Xata migrations isn't really something that helps you to iterate on a migration - rather the intent is that you can safely apply a migration to your database without breaking client applications that rely on a particular version of your schema - you can roll out a new version of an application while keeping the old ones running.
4 replies