Do not run `runMigrations` inside a giant transaction

[felixSchl]

Currently it's impossible to migrate "as much as possible" because either all migrations succeed or none of them do. While the behavior might be fine, it would still be nice to be able to turn it off. I think putting these two lines into a function and then writing a combinator that encloses the function in a transaction would work well.

[3noch]

I added that. Migrating "as much as possible" seems like a very dangerous thing to do. What's your use case?

[felixSchl]

I usually add for example non null columns in two migrations so that I can fix things up manually in between (add missing values). I suppose I could write a MigrationCode for that but during development I find it simpler to just do a one off job of providing these values and mess with things. I understand where ure coming from I just opened this issue because it seemed simple enough of a change and there was no way for me to implement sth even hacked together downstream since required functions are not exported. What do u think about a feature to migrate to a particular change? That could be best of both worlds?

[3noch]

I see. I think your use case is pretty rare (migrations that aren't automated seems to defeat the purpose), but you're right that not having some of those functions exposed makes it impossible to do anything else. I think it'd be fine to export the functions needed to rebuild the migration entry-point from scratch if you wanted to do something custom.