9336577abe
SQLAlchemy 2.0 connections do not autocommit, and on MySQL alembic reports "non-transactional DDL", so context.begin_transaction() is a no-op. Nothing in a migration run committed. It looked like it worked because MySQL implicitly commits on DDL: every ALTER/CREATE flushed whatever was queued before it, including the PREVIOUS migration's version stamp. The LAST migration of a run has no DDL after it, so its stamp was rolled back when the connection closed. `flask db upgrade` then exited 0 with the schema change really applied and alembic_version one revision behind, and re-ran that same migration on the next deploy. A migration that is not idempotent applies twice. Found while adding a core migration: the column default really changed and alembic_version still named its parent, with UPDATE alembic_version followed immediately by ROLLBACK in the log. Existing databases upgraded before this are one revision behind their real schema. Compare `flask db current` against `flask db heads`; re-running the upgrade re-applies the final migration once and lands the stamp.
Single-database configuration for Flask.