How to run a specific Ecto migration file in the console while preventing it to be tracked?

Questions / Help
,
1

I want to run a specific migration file but I want it to keep its pending status on next call of ecto_migrate.

Please, is quiet the right option to pass to the command?
Like for example:

mix ecto.migrate --quiet --to 20080906120000

And incidentally which option will allow me to run only one given migration file if there are several pending migrations?

Thanks

2

--quiet just surpresses output, or at least parts of it.

I do not think there is a way to run a migration without marking it as “done”. Also, I do not think its possible to run a single migration file out of order.

Migrations describe changes to a database schema over time.

1 Like
3

I guess I have to learn more psql commands…

Please, by any chance is there a way I can convert an Ecto migration file to pure psql command that I can paste in the psql console and execute it?

Edit: I mean I find it really easier to write Ecto queries instead of PostgreSQL ones.

1 Like
4

If you have queries that you need more often than once, wrap them in a mix task, if it’s one off queries, do them on iex.

1 Like
5

Ok how can I for example run something like drop_if_exists index(:posts, [:user_id]) in iex?

I tried like this and got some errors:

iex(2)> Ecto.Migration.drop_if_exists Ecto.Migration.index(:posts, [:user_id])      
** (RuntimeError) could not find migration runner process for #PID<0.828.0>
    (ecto_sql 3.3.3) lib/ecto/migration/runner.ex:100: Ecto.Migration.Runner.prefix/0
    (ecto_sql 3.3.3) lib/ecto/migration.ex:1175: Ecto.Migration.__prefix__/1
    (ecto_sql 3.3.3) lib/ecto/migration.ex:566: Ecto.Migration.drop_if_exists/1

Edit: I’m running from the iex session of an umbrella child web_app that needs core_app as dependency. The core_app is the one that contains the ecto repo.

6

But that’s an invasive query, altering the schema, you should run those properly in a migration to keep track of the changes.

1 Like
7

I guess you’re right. I have the bad habit to directly edit my old migration files instead of adding new ones to apply some changes to the database. at least as long as the project is not yet in production. Then I just drop the database and setup it again with the new changes. Like that a single glance at a given migration file tells me how for example a table is designed. Again one could argue that the migrations is not the place to get an overview of a database…

I don’t want to drop the database this time because I inserted some data for testing that I don’t want to re-insert again…

Edit: I guess I can just add a new migration file to apply to the database then delete the file without any consequence since I’ve also added the changes in the old done migrations.

8

I do this too.

As long as the app hasn’t shipped yet I just keep around a single migration file and I change it around as needed.

Another thing you might want to set up is a way to generate fake data for development. Then you can drop the db → run your single master migration file → generate new fake data in about 3 seconds once you get used to running the combo.

2 Likes