What is good practice with Xata's (Multi-version Schema) Migrations?
For now, we have used mainly Drizzle Kit for our migration needs. However, we are at a point where we would like to use Xata's Multi-Version schema feature.
What's a good workflow that allows for good DX and safe 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.
Do you have any experience/recommendations on how we could handle the experimentation vs. migration phase?
Multi-version Schemas have a lifecycle. Is this something we can use to solve this problem?
I need to be honest that I don't know how other tools handle it.
3 Replies
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.The 'multi-version' feature of Xata migrations isn't really something that helps you to iterate on a migrationOkay, thanks. I wondered if that would've been a nice side effect. So how do you specifically do this:
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.Could you make an example? In the past, with other tools, I generated the migrations and the rolled them back again until I had one that was "final". Is there a Xata tool that we can use to do that without having to manually create new migrations for rolling back one? And to finally create the multi-version migration if possible.
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:
[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.