Files
shopdb-flask/migrations/env.py
cproudlock 9336577abe Commit the migration run instead of trusting MySQL to
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.
2026-08-13 09:28:11 -04:00

170 lines
6.2 KiB
Python

import logging
from logging.config import fileConfig
from flask import current_app
from alembic import context
# Registers the compiler hook that forces utf8mb4 + DYNAMIC on MySQL. Imported
# for the side effect, and shared with the PLUGIN chains via
# shopdb/plugins/alembic_template.py - it used to live here, so it covered core
# only and plugin baselines inherited the server default charset.
import shopdb.utils.mysql_charset # noqa: F401
# this is the Alembic Config object, which provides
# access to the values within the .ini file in use.
config = context.config
# Interpret the config file for Python logging.
# This line sets up loggers basically.
fileConfig(config.config_file_name)
logger = logging.getLogger('alembic.env')
def get_engine():
try:
# this works with Flask-SQLAlchemy<3 and Alchemical
return current_app.extensions['migrate'].db.get_engine()
except (TypeError, AttributeError):
# this works with Flask-SQLAlchemy>=3
return current_app.extensions['migrate'].db.engine
def get_engine_url():
try:
return get_engine().url.render_as_string(hide_password=False).replace(
'%', '%%')
except AttributeError:
return str(get_engine().url).replace('%', '%%')
# add your model's MetaData object here
# for 'autogenerate' support
# from myapp import mymodel
# target_metadata = mymodel.Base.metadata
config.set_main_option('sqlalchemy.url', get_engine_url())
target_db = current_app.extensions['migrate'].db
# other values from the config, defined by the needs of env.py,
# can be acquired:
# my_important_option = config.get_main_option("my_important_option")
# ... etc.
def get_metadata():
if hasattr(target_db, 'metadatas'):
return target_db.metadatas[None]
return target_db.metadata
def run_migrations_offline():
"""Run migrations in 'offline' mode.
This configures the context with just a URL
and not an Engine, though an Engine is acceptable
here as well. By skipping the Engine creation
we don't even need a DBAPI to be available.
Calls to context.execute() here emit the given string to the
script output.
"""
url = config.get_main_option("sqlalchemy.url")
context.configure(
url=url, target_metadata=get_metadata(), literal_binds=True
)
with context.begin_transaction():
context.run_migrations()
def run_migrations_online():
"""Run migrations in 'online' mode.
In this scenario we need to create an Engine
and associate a connection with the context.
"""
# this callback is used to prevent an auto-migration from being generated
# when there are no changes to the schema
# reference: http://alembic.zzzcomputing.com/en/latest/cookbook.html
def process_revision_directives(context, revision, directives):
if getattr(config.cmd_opts, 'autogenerate', False):
script = directives[0]
if script.upgrade_ops.is_empty():
directives[:] = []
logger.info('No changes in schema detected.')
conf_args = current_app.extensions['migrate'].configure_args
if conf_args.get("process_revision_directives") is None:
conf_args["process_revision_directives"] = process_revision_directives
connectable = get_engine()
# Alembic creates alembic_version.version_num as VARCHAR(32), but some
# revision ids in this chain exceed 32 chars. On MySQL that truncates the
# stored id, so the next migration's version bump matches 0 rows and the
# upgrade dies. Force the column wide in its OWN committed connection first
# (keeping it out of alembic's migration transaction), so long ids never
# truncate - fresh or existing.
try:
with connectable.connect() as prep:
prep.exec_driver_sql(
'CREATE TABLE IF NOT EXISTS alembic_version '
'(version_num VARCHAR(128) NOT NULL, '
'CONSTRAINT alembic_version_pkc PRIMARY KEY (version_num))'
)
prep.exec_driver_sql(
'ALTER TABLE alembic_version MODIFY version_num VARCHAR(128) NOT NULL'
)
prep.commit()
except Exception:
# Non-MySQL backends (e.g. sqlite in tests) - alembic's default is fine.
pass
with connectable.connect() as connection:
# Relax the session sql_mode for the migration run. Some historical
# migrations seed reference rows with raw INSERTs that omit NOT-NULL
# timestamp columns (the ORM supplies those via Python defaults at
# runtime, but a raw migration INSERT does not). MySQL 5.x's lax default
# accepted that; strict MySQL 8 rejects it with 1364 "Field 'createddate'
# doesn't have a default value". Dropping STRICT_TRANS_TABLES for the
# migration session only (the app's own connections keep their mode)
# makes the chain portable across MySQL versions.
try:
connection.exec_driver_sql(
"SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION'")
except Exception:
pass # non-MySQL backends (e.g. sqlite in tests)
context.configure(
connection=connection,
target_metadata=get_metadata(),
**conf_args
)
with context.begin_transaction():
context.run_migrations()
# COMMIT THE RUN. SQLAlchemy 2.0 connections do not autocommit, and on
# MySQL alembic reports "non-transactional DDL" so begin_transaction()
# above is a no-op - nothing here commits on its own.
#
# It looked like it worked because MySQL implicitly commits on DDL: each
# ALTER/CREATE flushed everything queued before it, including the
# PREVIOUS migration's version stamp. The LAST migration of every run
# has no DDL after it, so its stamp was rolled back at close. The column
# changes survived (already committed by their own DDL) while
# alembic_version stayed one revision behind, so `flask db upgrade`
# exited 0 having silently re-run the final migration, and re-ran it
# again on the next deploy. A migration that is not idempotent would
# apply twice.
connection.commit()
if context.is_offline_mode():
run_migrations_offline()
else:
run_migrations_online()