I have many migrations that belong to the same table and essentially serve the same purpose, but they were just created later when needed.
For example, A table was created was 3 fields, later I decided I need more 2 fields , and then 5 fields. The first creates the tables, the other two alters it. But they are all acting at the same table.
How to merge 'the end result' of migrations (if a migration adds a column and another removes it.. It shouldn't be created from start) ..
Is there such thing? What do you do in this case? Am I doing it wrong?
If you are still developing your application and you are the only person developing it (you aren't working with a team), you can merge them all manually. Just move the end logic into the migrations that create the tables and delete the migrations that alter the tables. If you are working with a team, I am not sure the best way to go about this other than forcing your team members to reset their migrations and start over. Of course, this will delete any data in the DB. But you can always back up the DB content...
This looks like a lot of work if you have 50+ migrations.. Why nobody created a package for this.. This is so common! Or you usually just leave them the way they are?
When I develop and I need changes made to existing DB tables, I edit my current migrations and then reset and rerun the migrations and rerun the DB seeder. I don't like to have more than one migration per table, but that's just me. I don't know of a package that does what you want automatically.
@StarTrix Well, you're doing something wrong. Migrations are version control of your database and you should not merge or change them. It somewhat similar to rewriting history in git.
So if you're the only one working on the project, you are 100% sure it won't break anything (which probably will happen), it's still in early development, then you're free to do so. Otherwise just don't
There is a migration creator package (https://github.com/Xethron/migrations-generator) I think that after I migrate all files, I remove them and generate fresh ones from the DB (which will have the final structure) ... Will that work?
@JarekTkaczyk I'm the only one developing the project, and I don't find referring to something I changed in a successive migration to be very helpful , unlike code changes when using git.
@StarTrix, the entire point of the migrations is so that you can constantly build up your schema and not have to worry about different environments being out of sync. If you're the only person working on the project AND you only have it currently deployed on one environment (local) then there would be no harm in just copying/pasting your new fields into the original migration. You need to be very conscious about what other environments/databases you have set up though. If you've already ran the migrations on another database you are best to just leave them be.
The migrations are a form of version control, that's why they have up/down. For example, V1 of your project may require that your user only enter a first name and last name. You deployed V1 6 months ago and now you are working on V2 and you've decided to require a phone number from your users. V2's UP migration will add $table->string('phone') to your schema. V2's DOWN migration will remove the column ($table->dropColumn('phone');)
You deployed V2 and you realized it was nowhere near ready -- you need to immediately roll back to V1 before your client gets upset. Running migrate:rollback will roll your migrations back a stage, and your database schema will be back to the schema that V1 required until you are ready to migrate back up to V2, at which time you would run migrate again and your phone column would be restored.
My reason for consolidating migrations is to speed up tests. My assumption is that a tests that use the DatabaseMigrations trait is going to build up and rollback migrations after each test, and run slower.
I don't think this is something that needs to be done on every DB change necessarily. But, it would be nice to do every once in a while to keep your tests fast and codebase lean.
