3 ms·

You can run/test your migrations in a transaction and roll back if it doesn't work.

• jolmg 7y ago
  Not all problems are obvious, though. You can have an app work 100%, your database be completely coherent, and then realize some of the data is missing. It would be cool to not have to be so careful when committing migrations, needing to be absolutely sure that we're not screwing something up. This is similar to how one would be careful of changes done in source code before we learned how to use version control systems like git. I can go completely wild with git, deleting random files, overwriting others with random junk, sharing them to my coworkers, etc. It would only take a few minutes to fix that.
  • smt88 7y ago
    This is OK for git because updates to a repo happen maybe 100 times a day at the most. A production DB is changed potentially millions of times a day. If you have this goal from the beginning, you can create an append-only database, but that's orthogonal to migrations. To have "append-only" migrations is seemingly out of scope for mainstream database engines.
• deleted 7y ago
  [deleted]
• baq 7y ago
  sometimes, maybe, if you happen to run the right kind of DBMS...
• jyounker 7y ago
  This isn't always true. In MySQL many DDL statements can't be rolled back. See https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.htm... for an example.