We basically just copied the migration generator from ash_postgres into the other data layers knowing full well that they would need to be tweaked, potentially significantly. Your options are essentially
- don’t use the migration generator, and handwrite migrations (not in like an aggressive way I just want to point out that it is absolutely an option to use hand-written migrations)
- PRs welcome on improvements to the migration generator. Even if it’s just emitting warnings saying “hey, you have to write this bit by hand because we can’t make that change automatically”, or if it’s applying various known workarounds.
- write a script that will at least make your life a bit easier by deleting those files and regenerating
No magic fixes unfortunately, it’s just a truth that the sqlite/mysql data layers haven’t received even half as much love as ash_postgres. Not because we don’t care about them, they are just much newer and don’t have champions for getting their DX up to snuff w/ what ash_postgres offers. At Alembic we have tons of projects shipping using ash_postgres and its far and above our most used data layer, so it gets the most attention from me (for better or for worse 
)
