How to reliably combine unsafe/manual migrations with safe/automatic ones?

[alexfmpe]

It looks like the workhorse is runMigrationWithEditUpdate (is it intended that tryRunMigrationsWithEditUpdate doesn't specify a hook?), but it can be tricky to figure out how to encode things so that migrating from commit A to commit B will work regardless of whether it's done commit-by-commit (e.g. dev) or in one go (e.g. a deployment).

It looks like the idea is something like

1. specify the list of unsafe migrations to be run (and add to it over time)
2. get the entire list from runMigrationWithEditUpdate's hook
3. look at whether the subsequence of unsafe ones it's trying to do is a suffix of those you specified (i.e. we're in a state where any number of them might not be needed anymore, and all the ones after are needed), bail if that's not the case, then individually check that they're happening under the expected conditions, so you don't drop columns with data unless you opt-in, say, because you just converted/migrated that column.

Is this a reliable encoding? And if so, would it be worth adding a specialized helper for discoverability? Something like migrationHookFromExpectedUnsafe :: [(EditAction, EditCondition)] -> ([WithPriority Edit] -> [WithPriority Edit])

[augyg]

@alexfmpe I've been trying to work on a solution in line with what you point out and perhaps I still have some lack of understanding but I wonder if that would allow for more tricky updates, for example if you have a column of data and need to convert a type, you might use USING from Postgres but there seems to be no way to do this using the EditAction case of ColumnTypeChanged, which seems to be stuck with implicit casting?

So I suppose my question is, at some point would we need a way to run arbitrary logic at least for some of these cases of EditAction? If so I'd imagine we would need to include this more arbitrary logic into the database transaction here in runMigrationWithEditUpdate

[augyg]

This seems to be solved by: #50