In Rails we have a file called schema.rb which is an auto generated file that holds a versioned definition of current schema. schema.rb essentially allows you to only concern yourself with future migrations after a particular date, provided that you do not need to support instances of the application that are behind the schema’s datetime stamp.
I recently came across a Laravel app where the migrations had not been well maintained. Down functions were inaccurate or missing, some migrations contained code specific to a particular RDBMS, etc. So recreating the database was not fun and required a careful refactoring of the legacy migrations. The problem could have been avoided if the framework had a schema file and the legacy migrations did not need to be maintained.
Are we likely to see a schema.ex file in Phoenix and if not, why not? And what are alternative approaches to avoid having to maintain potentially hundreds of legacy migrations?
Ecto acutally does have the functionality you need. It is not, however, making the db structure dump after you run a migration automatically - like Rails does.
If you want to maintain a file with an up-to-date db structure, you need to recreate this file with mix ecto.dump. The resulting file will be stored in priv/repo/structure.sql.
Then, on the other machine you want to load database structure with mix ecto.load.
The SQL format vs. Ruby/Elixir format of that file I think it’s great choice. I’ve always had trouble with ActiveRecord’s schema.rb file - as soon as you start using extensions, functions, triggers or views it becomes impossible to stick to that. SQL is better.
Everything that @hubertlepicki mentioned is true. Also, if you want to run it automatically you can change the ecto.migrate task with an alias to mix.exs:
"ecto.migrate": ["ecto.migrate", "ecto.dump"]
This should dump the database structure every time you run migrations.
Is there a recommended/supported way of loading up the result of mix ecto.dump?
☛ hq1-squash-migrations* ~/dev/xyz $ ls apps/xyz/priv/repo/migrations | wc -l
340
This takes some unnecessary space and makes it very difficult to answer questions such as “what’s the latest change in a stored procedure BOOM()?”. A fuzzy search on the migrations directory makes it hard to pin-point the most recent migration (or maybe I could just fuzzy search the date range… )
I thought I’d just wrap up the dump file, remove all the existing migrations, and add an initial one, once again, to execute the dump, so the upcoming migrations could take it from there.
)
