Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I've researched this topic for a while, and many people said that just use the --seed option instead.
The --seed solution has its good points for the development environment, but how about the production environment? If you are not planning to modify the database structure manually, then you have to write a new migration for the modification right?
I'm very sure that our database structure will be modified again and again in the future as long as we keep improving the product.
What's going to happen then? Your migration files keep increasing gradually, 10,20,30.... I don't have the confidence to handle such a mess... Actually, even it's way more intuitive to create and modify the table manually... Once you've released your product you have to keep writing new migration files, and I believe that's the beginning of the nightmare.
So what's the best practice?!
(I just can't understand why it's a good idea to delete the data when refreshing the database... I thought it's nothing but chaos)
By the way, this is what I thought the relatively better and extremely ugly solution... You write a new migration file, you then migrate it, and delete the new migration file, lastly, modify the original migration file to match the latest database structure.
The data gets deleted cause the migrations will be rollbacked and probably every migration (at least the create_XX_table) of you has something like this:
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('users');
}
just create a folder, drop your migrations in and forget them (until you need them) they are not important for production after they got executed
No, it's going to get errors something like this because the table to be modify is already exists.
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'social_accounts' already exists (SQL: create table `social_accounts` (`id` bigint unsigned not null auto_increment primary key, `user_id` bigint unsigned not null, `provider` varchar(191) not null, `provider_user_id` varchar(191) not null, `created_at` timestamp null, `updated_at` timestamp null, `deleted_at` timestamp null) default character set utf8mb4 collate utf8mb4_unicode_ci)
Migrations are like version control for you db. You don't have to use them but they provide a convenient way to make (and reverse) changes to your schema programatically and see what changes you made at a certain point in time.
You can easily view and export your current schema anyways if you just want to see the current structure, can you not?
There are even packages for generating migrations from an existing schema: https://github.com/Xethron/migrations-generator
Man, this no makes any sense. Migrations are used this way, a new file after each modification. At producion environments, just use '''php artisan migrate''', without refresh, whats is the problem with this?
Man, this no makes any sense. Migrations are used this way, a new file after each modification. At producion environments.
Migration:refresh is clearing command in laravel so you can't save data from there if you want data you can back-up the SQL File and export-import data from SQL.
Man, this no makes any sense. Migrations are used this way, a new file after each modification. At producion environments.
Please or to participate in this conversation.