Hi,
Well, if you are still on early development, you can always run php artisan migrate:rollback, this will remove and delete all the tables that were created previously then you just need to update your migrations, in this case, add the index to the first migration and after that run php artisan migrate again.
The migrations exist for a very simple reason, once you go production and you need to update your database, you should always create a new migration, this way you are "versioning" your database, and if something goes wrong, you can always rollback to the latest batch.
So, if you already have data on your database, creating new migrations is fine and advised, but if your project is already on production, create new migration files.
Hope it helps to clarify it a bit.
The thing is if you change a migration, but that migration has already ran in other environments or you pushed it to github and there are other developers on the project, then the change you made won't be reflected in those environments. If you made the migration locally and didnt send that change to any other environments, then it is safe to roll it back and change it.I think migrations are less about version control, and moreso to allow all environments' table structures to be consistent. Because you dont necessarily rollback a migration in production, because then you have to go and rollback that in different environments where that code lives, so you essentially just create another migration that contains the logic for the rollback. But if your code only lives locally, then by all means, it doesn't matter.
OK, I see, this makes sense in the context of updating a production site with data.
Thanks.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast