noob making ecto migrations to production

Questions / Help
1

Is it good or bad to check in the migration in priv/repo/migrations/ to version control and then call mix ecto.migrate on the production server? what happens if you need to do more migrations to the same database later? do they all go in the same file or is this why you should avoid it.

2

It’s a good idea so you have a central book keeping for your migrations. When you want to do more migrations you simply create a new migration file using mix ecto.gen.migration.

Here is why it works

  1. When you make a migration file it gets a version number.
  2. When you run mix ecto.migrate it will run each migration file one by one and store the version of the file in a table.
  3. Later on when you have new migrations it won’t re-run the old ones because it checks the table and sees those versions have already been applied.
1 Like
3

thank you for that explanation. so if your migration deals with say a table foo and we make a migration file foo, would the next migration be called foo2? foo3? and so on?

4

You can technically name it whatever you want but I personally name them after the actions I’m performing. i.e. if my first migration creates table foo i call it create_table_foo. If my second migration adds a column called x to table foo I call it add_column_x_to_foo

1 Like
5

EDIT: ignore, this is BS, had a brain fart.

No, they get prefixed with a full date and timestamp so you can technically run 1000x times mix ecto.gen.migration foo and you’ll get a different name every time e.g. 20220901223758_foo.exs, then if you run the command again exactly one minute later you’ll get 20220901223858_foo.exs (notice 38 vs 37) etc.

6

When I tried that it said, (Mix) migration can't be created, there is already a migration file with name peepz1

7

EDIT: also wrong, see below. :003:

Oh, oops, I screwed that up. Yes you can’t, sorry. Reason is that the name of the migration is written as a record with an unique constraint – namely in the schema_migrations DB table.

1 Like
8

It’s actually only the version (timestamp) that gets saved into the migrations table. The name has to be unique because a module is created for each migration based on the name.

9

Another month, another idiotism from me when posting from the phone. I really should take the hint already.