Five existing migrations used op.alter_column / op.create_unique_constraint /
op.drop_constraint / op.create_foreign_key directly on the users + quotes +
quotes_daily tables. SQLite has no native support for those operations and
requires Alembic's batch_alter_table copy-and-rename workaround.
This wasn't noticed until now because the test suite uses
Base.metadata.create_all to materialise schema, not the migration chain
itself; and prod is MariaDB. But running `alembic upgrade head` against
a fresh SQLite database (developer onboarding, CI smoke tests, the
test container's own bootstrap) would fail at 0005.
Fixes:
- alembic/env.py: set render_as_batch=True when the dialect is SQLite.
This auto-wraps any future autogenerated migration but doesn't
retroactively rewrite existing op.* calls.
- 0005 (widen quotes.symbol), 0013 (referrals), 0018 (polar webhook),
0019 (stripe), 0023 (users.lang index + qd_symbol widen) explicitly
wrap their problematic ops in `with op.batch_alter_table(...) as bop`.
Now `alembic upgrade head` + `alembic downgrade base` round-trip cleanly
on a fresh SQLite database. MariaDB prod behaviour unchanged.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Giorgio Gilestro
78ce8c8b0d