[12.x] Introduce Migration@shouldPrune()

[cosmastech]

What

Allow specifying if a migration should be considered prunable by the schema:dump command.

Why

We often insert data into our DB via migrations. While we could do this via a seeder, it's really not terribly convenient. Having data insertions done in migrations disallows us from taking advantage of pruning our migrations into a single SQL file.

Why not just use seeders?

This requires a person to SSH into each environment and run a seeder upon deploying the code changes. This is easy to forget to do. It also requires all devs on the team to be bothered to run a seeder. This coordination costs time and headaches.

Furthermore, say we have a seeder that stores four fiscal years in our budget. Next week, our product owner tells us that we actually need to add another year into the future due to product reasons that no developer really understands. What are the options here? Create a seeder that adds a single entry? Modify the existing seeder but disable foreign key checks, truncate the table, and then re-insert?

How

Here we have simply added a method called shouldPrune() to the Migration class. This is akin to the shouldRun() method that was added earlier this year by @danmatthews. The method can be overridden in these migrations where data is being manipulated in the database.

This will slightly slow down the schema pruning, as it is going to instantiate each Migration class to check if it should be pruned or not. Since I would assume this command is run infrequently, I don't think this risk is terribly great.

I have also modified the MigrationsPruned event to include a list of the migrations that were deleted. Don't know if anyone would ever need that, but there they are.

Gotchas

It is on the developer to know if the migrations they are marking as non-prunable will have side effects if the rest of their schema has been dumped to a single file.

Potential breaking change

I have updated one method in the Migrator class from protected to public. I could work around this by writing a public method which calls the protected method 🤷

Hey, where are the tests?

I noticed that this command didn't have any tests to begin with. If requested, I can figure out that how to make that happen.

Here's a screen recording of this working locally:

should_not_prune.mov

[cosmastech]

The $database variable was unused, probably a relic from the time before PHP had named args.

[taylorotwell]

I honestly worry this would have a lot of gotchas as you mention, especially in regards to the order things are run. You would really have to think hard about whether this migration can be run after all of your other migrations even though it existed in a certain point in time when maybe the database was in a different state or the schema was in a wildly different state.