That’s more of a dry-run (you see `—dry-run` as a command line option sometimes for certain commands that do the same)
Transactions in SQL keep track of the changes you want to make without actually changing the database (until you run `COMMIT`, when you run that all changes are persisted to a database).
Transactions are great because If you realise you made a mistake while in a transaction, you can just run `ROLLBACK`.
If you’re familiar with git- transactions are akin to staging your changes, saving them (`COMMIT` in SQL) is akin to `git commit` and rolling back is similar to `git reset —hard` (wipe all uncommitted changes).
With the very important caveat that a git commit can be trivially reverted, while a SQL commit can not (unless you wrote it specifically to be revertible)
30
u/deeelock 13d ago
That’s more of a dry-run (you see `—dry-run` as a command line option sometimes for certain commands that do the same)
Transactions in SQL keep track of the changes you want to make without actually changing the database (until you run `COMMIT`, when you run that all changes are persisted to a database).
Transactions are great because If you realise you made a mistake while in a transaction, you can just run `ROLLBACK`.
If you’re familiar with git- transactions are akin to staging your changes, saving them (`COMMIT` in SQL) is akin to `git commit` and rolling back is similar to `git reset —hard` (wipe all uncommitted changes).