To clarify, does this mean that DDL is now fully transactional the way it is in postgres?
To clarify, does this mean that DDL is now fully transactional the way it is in postgres?
https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html
> DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACTION ... COMMIT, or combined with other statements within the same transaction.
Sounds like it just means that single ALTER/ADD/REMOVE statements now cannot fail in an intermediate state, but a sequence cannot be run in a transaction, so there's still a manual process to unpick a migration that failed half-way through. (That's always fun in production...)
Perhaps the groundwork has been laid though, and it'll be possible in 9.0.
That sounds horrifying. Implicitly committing transactions could very well leave the database in an undefined / inconsistent state, no? That is, from the applications view, if I do:
BEGIN;
STATEMENT A;
STATEMENT B;
END;
I would expect either both or neither to succeed, but that paragraph would suggest that A could succeed, and the transaction be committed. (And who knows after that?)Am I missing something?
That means any previous version could fail during DDL execution and leave your metadata in an inconsistent state that you couldn't recover.
Now MySQL is about as good as any commercial database.