benswift
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest Ash Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 5 of 5 Posts
zachdaniel
We basically just copied the migration generator from
ash_postgresinto the other data layers knowing full well that they would need to be tweaked, potentially significantly. Your options are essentiallyNo 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/ whatash_postgresoffers. At Alembic we have tons of projects shipping usingash_postgresand its far and above our most used data layer, so it gets the most attention from me (for better or for worsebenswift
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.
zachdaniel
What might be a great middle ground is if you could document in issues the various behaviors that bite you and the problems the caused. That way we can at minimum catalogue them
benswift
Roger that, will do. I remember a while ago you recommended a single-file ash app thingy which was useful for creating reproducible errors. I’ll try and track that down.
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