Framework: Add DatabaseMigrator

[arce701]

• Laravel Version: #.#.#
• PHP Version:
• Database Driver & Version:

Description:

It would be opportune to have the option where you can put the order to carry out the migrations, just as it is done with the seeds. This would avoid relational integrity issues when new tables are added.

Steps To Reproduce:

[themsaid]

Migrations are already ran in the order they are created, you just need to count for foreign keys constraints :)

[arce701]

The problem is just that they are executed in the order that is created, sometimes we need to add a table after a time, and we must make two migrations one for the table and another to add the field with the foreign key. With the idea that I propose everything would be simpler.

[arce701]

I would have liked to have it discussed before closing it so soon

[sede2]

If you have to create a table and modify another one, you are supposed to create two migration files. (or at least add the column in the same migration where the Schema::create of the first table is made)

[themsaid]

I'm saying that you control the order of migrations already, if you want to change the order later you just have to update the timestamp in the file name and that's it.

[chrisblackwell]

I think this would be a great idea. @themsaid You shouldn't have to change the timestamps, as they are there for multiple reasons. Having an order in which to migrate, like how the Database Seeder works, is valuable, and I think could be added.

[themsaid]

@chrisblackwell feel free to suggest an implementation on https://github.com/laravel/internals repo, that's where we keep proposals or feature requests.

On a side note, changing the order of execution is not a usual action, so changing the timestamp can be a workaround to reach what you want, I don't think adding an extra step to register a new migration like we do with seeders is good, but that's my opinion :)

Please open the discussion on the internals repo :)

[sisve]

I'm always truly fully 97% hostile to anyone trying to change how the migration system works because [insert reason here]. It's usually from people that have misunderstood how migrations work, and how important it is to keep their order of execution.

Your database structure is a long list of changes. You start with an empty database, then create a table, change a table, create a table, etc. It's like a travel route that tells you how you ended up where you are. What you're now describing is changing out that "turn left" with a "turn right", but that has high potential to mess up your entire journey and you will no longer end up at the same place.

This is why there's a common practice to never change a migration once it has left your machine. As soon as it is pushed to a common repository someone else may have checked it out and executed it, so you can no longer change it since those that have executed before the change will not automatically execute it again.

Migrations are like version control for your database, allowing your team to easily modify and share the application's database schema.
Source: https://laravel.com/docs/5.4/migrations

What you describe would be similarly to deciding to change a git commit made months ago. Yes, it is possible but your entire code base would diverge from the original at that point, and all your commit ids would change and every other person involved in the project would now see oddities. That's why it is only done by those that spread pain and suffering.

@arce701 It would be opportune to have the option where you can put the order to carry out the migrations, just as it is done with the seeds. This would avoid relational integrity issues when new tables are added.

This means that your dev and your production would no longer match. The migrations in production has already executed in a specific order, your migrations in dev needs to do the same to produce matching results.

[...] sometimes we need to add a table after a time, and we must make two migrations one for the table and another to add the field with the foreign key.

You can get away with just one migration that changes two tables. There's no requirement for you to have one migration per table/change. So, one migration that adds the new table _and_ adds the new column+fk to an existing table.

@chrisblackwell You shouldn't have to change the timestamps, as they are there for multiple reasons.

What are the other reasons, except for the order of execution?