Schema migrations

[rob-c-baker]

Currently, if you create or modify fields (i.e. not data but schema stuff) in a "content" migration, this modifies project config, which is expected and 99% of other times exactly what's needed.

However, if you do this in a non-live environment and commit the resulting project config which then goes live in the same release it can behave entirely differently (I'm thinking automated deployment via CI) because php ./craft up will always do plugin migrations and sync project config before it runs content migrations. This can change the fields before the migration that might have been designed to copy data around. Worst case: the field a content migration was expecting to copy data from has been deleted.

I know this can generally be solved by breaking the process into multiple releases, i.e. if moving data between fields:

1. Create the new field
2. Copy the data from old field to new
3. Delete the old field.

I would like to think that perhaps this could be solved (or steps reduced) if there was a built in "schema" migration track (not sure of the name) that ran before the project config sync.

One way of doing this is by having a plugin (opposed to module that does not have a migration track by default) that just houses a migration track but that seems a bit tricky to maintain.

I have seen various ways of having a separate migration track but as I understand it these don't get triggered by craft up and so don't get niceties like a mutex covering the process.

[rob-c-baker]

As I'm going through a few cases that move field data around at the moment:

It seems the best bet right now, if you are changing field schema is to create a migration to do it (or do it manually), run it in a dev / test environment, commit the resulting project config and delete the migration. Then make another migration that is purely concerned with transferring data, test and commit that and put both in the same release. If both the project config and the "schema" migration end up on the same release things can go sideways as the migration is trying to repeat what the project config just changed.

This can then be followed up with another release if the aim is to delete the fields that were the source of the data.