Generate migrations from Ecto.Schemas or use those Ecto.Schemas to create tables in database

Questions / Help
1

Is there any way to generate migrations starting from the defined schemas?

I need to do this because I am working on a project that does not have any migration files, it only has the defined schemas and the data model is quite large.

Or maybe there is some other way to create the tables in the database without having to write the migration files manually?

Thanks!

1 Like
2

I’m not sure if there is any way from which you can create these migrations. But for all, I know you have to write the migrations.

1 Like
3

Hey, thanks for replying.

And do you know if there is any way to change the order of migrations? i ask you this because the project has some migrations that depend on others that do not exist. For example:
there is a migration that alter a table named “devices”, but there is no migration that create that table, so it raised an error because that table does not exist, so i generated a new migration that create the “devices” table but it keeps throwing the same error, i guess that it is because the migration that create the table it is generated after the migration that alters that table.

Again, thanks for replying!

4

The idea of reordering migrations goes agains the principles that migrations represent.

Think of migrations as a git log for databases. You only ever add to the git log. And you can’t rewrite history (well, not without significant work and risk - which I suspect is part of your current scenario).

Having them act like a “git for databases” is really powerful because it allows you to confidently ensure the state of your database is in a consistent and repeatable manner at a given point in time. Check out any commit in your repo, reset and migrate your database and you’re in a known state.

With that in mind, getting comfortable with generating a new migration every time you want to make a schema change is the happy path. Editing existing migrations is the sad path.

3 Likes
5

If this is for an already existing and working application then I do agree with Kip that you should try to avoid modifying already existing migrations (because those migrations won’t be re-applied in existing prod/staging/dev environments). But to me it sounds like you might not have launched this project yet in which case it is fine to re-order and modify migrations.

Ecto migrations are ordered based on the alphabetical ordering of their file name. So if you have some migrations like this:

ls -l priv/repo/migrations/
20210313200540_add_initial_tables.exs
20210425173306_create_users_auth_tables.exs
20210503201003_create_image_attachments.exs

And you want to move the create_image_attachments before the create_users_auth_tables then you’d change the filename from:
20210503201003_create_image_attachments
to
20210425173305_create_image_attachments
(i.e. 1 less than the create_users_auth_tables).

After you do that you should probably drop and re-create and re-migrate your development database (but of course only drop the database if you don’t need any of the data contained in it)

2 Likes
6

I suppose if phoenix task for schema generation is able to generate migrations you are too able to create migrations for existing schemas if they are straightforward. Take a look at the code phoenix/phx.gen.schema.ex at fa900d6b57e0b14dfa73019338c8b41af3734156 · phoenixframework/phoenix · GitHub. As it seems it is based on quite simple EEx template file.

7

Reading OP I believe they’re more after something like mix ecto.dump which can then be mix ecto.load-ed inside of an initial migration file that’s named e.g. 20000101000000_load_initial_structure.exs.

1 Like