Laravel Migrations 'Trick': Rename File Timestamp to Run Earlier

A quick trick I remembered while working with a new upcoming demo project.

- - - - -
Support the channel by checking out my products:

- - - - -
Other places to follow:

[adilomer]

Haha, just two days ago I faced a similar problem. I had over 20 tables, and I ended up changing the timestamp on the tables just like you did.

[amazingrajeev]

I used to use this trick to decrease the quantity of migration files while starting any new project and also when project is not deployed in live and not being used as production with live production data.

[saravanasai]

That is a hack to do. I have used this on some while starting new projects & creating all migrations & database tables for initial setup.

[pauloclara]

If you have to refresh the db, as is the case, I prefer to create related tables in the same migration, I think it is easier than having many files in the migration

[BelgranoK]

Another aproach is to create the two tables in the same migration file. I saw that in several packages and the Laravel framework itself.

[webdesign]

Hello please if you can give us you way how you compact data to the view blade file if you have big data passed
for example you have create product view and you need to show dropdown list of sellers, categories, brands (thousand records foreach)

The view will take time to load what's the best solution or way to do that
Thanks

[L-A-O-S]

Well, the discovery of this trick suggests itself when you see the date in the title of migrations

[PabloZagni]

As you said, you can do this if you didn´t run it in production... if you are in a development sprint. But it's not a good practice.
If you have: Mig1, Mig2, MIg3, you run in production, and then you create another migration like Mig21 (between Mig2 and Mig3) laravel will apply it... Am I clear?

[makofguitar]

I've got this trick while learn laravel 5.

[Daemia-oq]

i very often rename migrations files, but for me there is an other problem.

I have multiples tasks being validated on pre-production environnement. Each task can take, a few days or a few weeks to be validated. When each task is validated we merge them into master and we can deploy a release.
The problem is that then the migrations order won't be enforced.
Task one, migration monday. Task two, migration wednesday. Task two can go to master before task one. This has never caused me a problem until now but I know it could.

[TalesGrechi]

Yeah, I had to rename it like that, too 😅

[KMehdi]

Hello, additionally, the plugin might be helpful