Changing Migration Order

Sadly there's no other way. you must change the timestamps manually.

Bleh, really? That seems pretty inconvenient, I'm surprised a more direct management system isn't there. Is this just not a problem people usually run into? Is my workflow causing me to have this issue where I shouldn't?

Yes, plus even if you'd like to create a package or tool for it, how is it gonna work? It is a bit hard.

Hey @lcopeland, I think it may help to understand the motivations of migrations. The idea is to incrementally make changes to your database schema so they can be applied in order, and when you've deployed a real life application, changes can be made to your database without rebuilding the whole database from scratch.

So each time you make modifications to your schema, you should be creating a new migration rather than editing old ones.

If you've created migrations out of order, maybe try adding a new migration after them to add your foreign key constraints.

Hope this helps :)

@lcopeland

Is my workflow causing me to have this issue where I shouldn't?

Don't know your workflow but to avoid this kind of things, I like to model my database with this https://en.wikipedia.org/wiki/Relational_model .

It's a little time consuming, but that way you can see your project with a global point of view instead of just digging in and in and fix bugs or so when they show up.

@jaewun ok, that helps me out a bit in understanding why they're the way they are. I was thinking about them more as a structural tool than version control.

That being said, I'm not sure I actually really want version control. I've been using migrations mostly to have more direct and easy access to my database structure, and to be able to easily rollback changes when I'm altering my table structure. I don't need backups of every bit of experimentation I do, and I kind of like the convenience of having one file per table that I can micromanage. Are there any alternative packages to migrations that would offer more functionality as a design/seeding technology?

You would be looking for a schema type thing. Migrations are not really that alone

Being able to change the order of migrations would be handy, although there is a risk as people have said that it would break the idea of migrations in the first place.

The use case you're explaining is probably one I'm in right now as well. You are building an app which is not released and can be totally rebuilt for testing purposes. That is, you can run a full migrate refresh and reseed for a while until things become stable. So it's really more useful to be able to create a migration, and place it earlier as you learn what other related tables you need.

For example, you'll often normalize things more over time and realize that instead of an enum column you really need a lookup table with a 1-M relationship. But you would prefer having this table built before another migration which has a FK relationship to it.

I think for now really it's best to just hack it by changing the timestamps.

If you really want to do it properly, you could temporarily turn off foreign key constraints in the migrations, do the work and then turn them back on....

DB::statement('SET FOREIGN_KEY_CHECKS = 0');

Then after you've done some work turn it back on!

DB::statement('SET FOREIGN_KEY_CHECKS = 1');

I haven't done this with migrations, so not sure how well it would work but there's an idea... probably not a great one though.

Well, as told before, the concept of migration is a little bit different, but, practically, when this happens I usually do something like this. Backup and eliminate your migration/s file/s that is/are "out of order". Create the new one/s like that:

php artisan make:migration create_mynewtable_table --create=mynewtable

Drop and create again your database, recreate the migration table like that:

php artisan migrate:install

then you are able to recreate the tables in the right order:

php artisan migrate

If you have seeds:

php artisan migrate:refresh --seed

Hope this can be useful.

I think I have found a different, and hopefully better, solution. My team and I use MySQL workbench and EER diagrams to decide on the relations between tables and it became my responsibility to then create the migration files. Instead of trying to decide that "I need to create this table before that table because that table depends on this table", I created all the tables without any foreign keys using the:

php artisan make:migration create_mynewtable_table --create=mynewtable

and after all those migrations were done then I went back and created update_mynewtable_table files with:

php artisan make:migration update_mynewtable_table --table=mynewtable

and placed my foreign key constraints in those files. This way the dependent tables have all been created before the foreign keys are inserted.

I'm also not a big fan of this. apparently there is a really simple hack to fix this by manually changing the timestamps

https://stackoverflow.com/a/32524465/4901013

This approach is a bit more radical - artisan migrate --pretend > script.sql captures roughly what each migration does as sql

needs a little manual cleanup
    strip the first word of each line (it's the migration name)
    suffix each line with ';' 

in this script, 
    you can move table create stmts first,
    then the alter tables
    then the indexes and foreign keys

mysql dbname 
@script.sql

Hi everybody your answer is here: https://stackoverflow.com/questions/32524101/laravel-change-migration-order

This problem was a bit annoying because I wasn't applying new migrations. I was building out migrations altogether and just happened to build the migrations for a table with a fk before the table that was referenced. It's all good now but that was annoying especially considering the mysql error doesn't indicate that the table doesn't exist "1824 Failed to open the referenced table".

Seems like a mysql skill issue + Laravel skill issue on my part.

Also I was reading using foreignId() in the migration with MySQL is not ideal due to issues with sql dump. Anyone concur with that?