Previously, I made the case for using the DB facade instead of an Eloquent model when a migration needs to change data.
Aaron pushed back a little when reviewing yesterday's tip, and made me defend my explanation.
I have to say, his instinct was a good one. Everywhere else in a Laravel app, we avoid magic strings and use the class reference directly instead. For example, we prefer using model class names inside validation rules that accept them, and we reference commands by their class rather than a string name.
This class-based approach makes it easier to safely rename that class later, and it powers all sorts of useful tooling inside the IDE.
This is the root of why Aaron pushed back. Why was I essentially making the opposite argument inside a migration?
One of my arguments is that a migration is already built on magic strings.
You write Schema::table('users', ...) without a second thought.
It's the way we have to do it.
There is no class that represents the users table exactly as it existed on the day you wrote that migration.
Because of that, I think it actually makes sense in this one context to continue the pattern and refer to table names, just like we do when managing schema.
And as I mentioned in yesterday's tip, we also have stability issues with model deletion and renaming, and unexpected behaviors triggered by observers or other events that can be introduced at any time in the project's life.
So layering the argument of consistency on top of the real-world potential for breaking historical migrations, I think the case gets a lot stronger.
Best of all, Aaron agreed!
This is the one spot where we make peace with the magic string, on purpose. The table name is the more stable contract, and a migration is exactly where that stability matters most.
Here to help,
Joel
P.S. Aaron came around on this one, but he doesn't always. If you want to take a shot at telling him he's wrong, come give it a try in the community.
