[carterehsmith]

So this is true, but I find that it does not matter much.

Like, how often one needs to rollback a DDL statement? I did that like... never.

And, what is the use case? Like, you added a column to a table by accident? Well, that will not break anything, so no harm done.

That is way different from regular dml rollback which may recover 1bn records and save your life :)

[astura]

Seriously? You don't need to do DLL operations in day-to-day use but you'll need to when you're doing development work.

For example, you had a "color" column on a table, for a new feature youre now adding the ability to have multiple colors. You're going to create a new column, create a new table, populate that table, and drop the old column. If anything fails during that process you'd like to be able to roll back.

[carterehsmith]

Good points, I am familiar with the process.

There is a concept or "forward-compatible change". Basically, you don't do things that will break your software.

Example, you don't add a NOT-NULL column unless you can give it a good DEFAULT value, to make it work.

Also dont' drop columns until the software is ready for it, etc.

If you have a decent ORM, it will compare your "how it needs to be" sql schema with the "how it is" schema. Then it will generate appropriate "ALTER TABLE ...." "CREATE INDEX " etc statements. Note that this is automated and you never need to type SQL statements to achieve that.

All together in the last XXX years, I did not really need to do a rollback on a dml statement.