skip to Main Content

Taylor Otwell said something controversial but I had a gut feeling about it for a long time.

"My view on that recently, in a past year, has been that you just never rollback. Ever. You would always go forward. Because I don’t know how you roll back without losing customer data. At least for my own projects like Forge or Envoyer, I could never really guarantee that I wasn’t losing data, so I think if at all possible, what I would try to do is write an entirely new migration that fixes whatever problem there is, and it would just migrate forward. Sometimes, if it’s low traffic, and you feel pretty certain that no one’s messed with the new database schema, then probably you could just roll back, but.. I’ve actually stopped writing down() methods in my migrations entirely, recently, now that it’s optional. But it’s really mainly feasible in Laravel 5.5, cause you have the new db:fresh method which just totally drops all tables without running down methods."

if Laravel creator himself doesn’t use it, why should we?

2

Answers


  1. Yeah, in most cases we probably don’t need to write down() methods. And rollbacking migration can be painful sometimes if done poorly. I also prefer to just erase the database and start again with db:fresh as Taylor said.

    But it is useful when you are in the early stages of development and the database schema isn’t clear yet to the team. Then you can find some uses for rollback in order to setting up your database schema (like putting/removing database types validations, like column sizes, column type, foreign keys, etc)

    Login or Signup to reply.
  2. I approach the topic as a "better to have it and not need it, than to need it and not have it" type of situation.

    I agree, rollbacks are very rarely a good idea due to the potential data loss. But a use-case that comes to mind where a rollback might be best in production is a situation where you need to rollback a release. Say you make a migration to alter a table, maybe add a new required column, rename a column, or similar. Your code is almost certainly coupled to that database change. If the new code is deployed and you must rollback the deployment, your previous code will crash when inserting into that affected table. In this case, a migration rollback is essential for quick recovery

    So while you could argue that migration rollbacks are very rarely a good practice, I still personally recommend writing the down methods.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search