Imagine me adding a new field to MySchema and some other changes.
If I do Repo.update_all(MySchema, …) in the migration before the field is added it’ll crash.
One could say it’s fine to use Repo just with table names, but then again you’re still starting your whole application just to have slightly more convenient api around queries.
It’s essentially the reason behind this for rails if I’m understanding correctly. GitHub - jalkoby/squasher: Squasher - squash your old migrations in a single command · GitHub
This approach seems reasonable, I will try it to squash all my migrations before 2022:
https://medium.com/@moxicon/collapsing-ecto-migrations-c58a32b6a4f0
I’ll let you know how it goes
Everything went smoothy, here is how I did it to squash everything until 2021.
MIX_ENV=test mix ecto.drop
MIX_ENV=test mix ecto.create
MIX_ENV=test mix ecto.migrate --to 20211223095738 # last 2021 migration
MIX_ENV=test mix ecto.dump -d priv/repo/schema-squash.sql
mkdir priv/repo/migrations_archive
for i in {2016..2021}; do mv repo/migrations/$i* priv/repo/migrations_archive; done
mix ecto.setup
And here is my mix alias in mix.exs:
defp aliases do
[
...,
"ecto.setup": [
"ecto.create",
"ecto.load -d priv/repo/schema-squash.sql -f --skip-if-loaded",
"ecto.migrate"
]
]
end
EDITED after @LostKobrakai hint
Adding more from @whatyouhide to this conversation Get Rid of Your Old Database Migrations – Andrea Leopardi
It’s worth mentioning that if you need to run migrations from within a release, you have to be rework the commands and watch out for the file path.
