just felt the need to actually test a migration—like literally write a test for an “add_slug_columns.php” migration.
anyone else ever had this need or something similar? specially because this migration will actually put data on this new column. 🤔
How do you approach migrations that require to add or alter data? We used to do it in the migration itself but later moved to keep the migration for changibg the schema and creating a seeder for the data manipulation. Never been happy with either solurion.
Just because I need to remember to run the seeder in order to populate/fix the data. It's not obvious, and also that means running a seeder on production, and when you see the promt asking if you are sure... I always get cold feet 😅
That's why I'm curious how you approach this.
I sometimes use a command instead of a seeder, to create some specific records. But that's still something you need to remember to run. Not sure if there's a smarter/frictionless solution.
Maybe you could just add a memo in the README of the project: "when this happens, add these records to the XY table: ..."
We have been manipulating data in the migration itself. What issues did you face @albert ?
If you fix your data in the miration, and you have to add or correct a lot of data, the migration can take a lot of time to finish. Even sometimes the execution could crash, and re-running a broken migration is not straightforward (likely you will get an error like the table or column already exists, and you need to fix it manually). It is safer to run the migration and then a seeder to fix the data, but then you need to remember to do it.
