benswift
Ash_sqlite generated migrations
Hey team
I’m building a new ash phoenix app with a sqlite3* backend (everything up-to-date, mix hex-outdated shows all green). Because I’m early in the development process my resources are changing a lot as I “explore the domain”.
I keep running into issues where the auto-generated migrations (i.e. mix ash_sqlite.generate_migrations) try and do things which would work fine in postgres but don’t work in sqlite3 (here’s one example, but I’ve run into a few different similar scenarios).
My current workflow is to
- sigh heavily
- delete all the migrations and resource_snapshots in the app
mix ecto.reset- start again with a new
mix ash_sqlite.generate_migrations
It’s kindof cheating, but since I’m still early in the development (nothing deployed to prod yet) I can get away with it.
I can think of a few ways I could do things differently:
- modify the generated migrations to use the various workarounds required to make sqlite3 actually do the things (may require
executeing a bunch of raw SQL in the migrations, but I’m ok with that) - modify the
generate_migrationstask so that it automatically applies the workarounds (happy to contribute these upstream, too - but I’m not sure how robust the detection will be and I’m not sure you wanna go down the “apply hacky workarounds” path withash_sqlite) - never make these breaking changes to the tables, and just work around things in app code (might be necessary in an existing app which can’t tolerate the downtime, etc, but that’s not my situation - so I don’t want to go down this path)
- switch to postgres
- some other option I’m missing?
Anyway thanks heaps for all your work on Ash - it’s an amazing stack, and I don’t mean to complain. Just want to know the best way forward given my situation.
*why ash_sqlite? I’m working on several small “proof of concept” apps, none of which have “precious” data, and I love the ops simplicity of using sqlite. And although I haven’t heard much from the litefs crew recently I do like that idea (since my apps all on fly anyway). So I’d rather not take option #4, and given that `ash_sqlite_ is a thing I guess you want to provide the sqlite option.
Marked As Solved
zachdaniel
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 
)
Also Liked
benswift
Hey mate thanks for the quick response. And I completely understand your (and Alembic’s) postgres-first approach. Hi from Canberra, btw 
I think my plan is to do #1, but I am open to submitting PRs as per #2 - especially the “emit warning, with advice on potential workaround” thing. I’m a vaguely-competent db guy, but not a guru (my expertise lies elsewhere in the stack). So I’m reluctant to put myself forward as a go-to for tricky db workarounds, but I guess I can see what works for me and then make suggestions to see if they’ll work for others. IOW I might not be the champion you’re looking for, but I can possibly help a bit.
And I’ve actually done #3 already So I may just keep trundling along with that approach until I’ve actually shipped something.
joelpaulkoch
Hi, I just want to add that this website has guides for some scenarios including " Using SQLite ALTER TABLE for other actions" (other than renaming) here: SQLite ALTER TABLE & How To Overcome Its Limitations
Popular in Questions
Other popular topics
Latest Ash Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"