Remove IF NOT EXISTS from migrations and drop mysql CLI fallback#19
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e506dffb1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| -- ─── Channels ──────────────────────────────────────────────────────────────── | ||
|
|
||
| CREATE TABLE IF NOT EXISTS channels ( | ||
| CREATE TABLE channels ( |
There was a problem hiding this comment.
Removing IF NOT EXISTS here makes the initial schema file non-idempotent, but the repo still has raw-SQL fallback paths that re-run migration files directly (scripts/run-tests.sh:118-127 and justfile:128-142) and suppress mysql errors with || true. In environments without sqlx (common in CI/dev shells), those paths will now hit "table exists" on the first CREATE TABLE, stop executing the rest of that file, and still report success, which can leave schema drift undetected.
Useful? React with 👍 / 👎.
- Drop IF NOT EXISTS from all CREATE TABLE statements in the initial migration. sqlx tracks applied migrations in _sqlx_migrations and guarantees each runs exactly once; the guard was masking partial failures and giving a false sense of idempotency. - Remove the mysql CLI fallback in dev-setup.sh. Running raw .sql files via docker exec bypasses sqlx migration tracking, which causes re-apply errors on subsequent runs. Fail fast with a clear install message instead.
baxen
force-pushed
the
baxen/remove-if-not-exists-and-mysql-fallback
branch
from
3e506df to
3b65b90
Compare
2 participants
What
IF NOT EXISTSfrom allCREATE TABLEstatements in the initial migration.mysqlCLI fallback path indev-setup.sh.Why
IF NOT EXISTSin managed migrations is an anti-pattern.sqlxtracks applied migrations in_sqlx_migrationsand guarantees each runs exactly once. The guard was masking partial failures and giving a false sense of idempotency — theCREATE TABLEmight silently succeed while subsequentCREATE INDEXstatements fail.The
mysqlCLI fallback bypasses migration tracking. Running raw.sqlfiles viadocker exec mysqldoesn't record anything in_sqlx_migrations, so a subsequentsqlx migrate runwould attempt to re-apply the same migration and hard-fail (especially now thatIF NOT EXISTSis removed). Two code paths for the same operation is a recipe for inconsistent environments.The script now fails fast with a clear
cargo install sqlx-climessage instead.Changes
migrations/20260306000001_initial_schema.sqlCREATE TABLE IF NOT EXISTS→CREATE TABLE(9 tables)scripts/dev-setup.sh