From f84dc3d02026d0ea5564c2d88abce79ad3427046 Mon Sep 17 00:00:00 2001 From: NguyenND Date: Tue, 7 Jul 2026 10:34:06 -0400 Subject: [PATCH] July 7 - Fix alembic script errors --- CLAUDE.md | 5 +++-- ...t_notify_recipients.py => phase33_contract_recipients.py} | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) rename migrations/versions/{phase33_contract_notify_recipients.py => phase33_contract_recipients.py} (97%) diff --git a/CLAUDE.md b/CLAUDE.md index f3fd87d..af0a145 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -701,7 +701,7 @@ phase1_projects_roles → phase6_features → phase7_mobile_api → phase8_notif → phase30_device_registry → phase31_device_registry → phase32_device_token_columns - → phase33_contract_notify_recipients ← HEAD + → phase33_contract_recipients ← HEAD ``` ### phase21_performance_indexes @@ -776,7 +776,7 @@ These three migrations are the history of a **false start** in device tracking. **The dead `DeviceRegistration` model, `app/api/devices.py` endpoint, and `api_devices` blueprint were removed (July 2026).** They defined a *second* `POST /api/v1/devices/register` that was shadowed at routing time by the `api_auth` copy and would have crashed anyway (it queried the dropped `device_registrations` table). Device registration now has a single implementation: `register_device()` in `app/api/auth.py`, writing to `api_device_tokens`. Do not reintroduce a competing device model or a duplicate register route. -### phase33_contract_notify_recipients +### phase33_contract_recipients Creates the `contract_notification_recipients` table backing **per-contract additional notification recipients** (see §5 `ContractNotificationRecipient` and §11). Uses table existence check — safe to re-run. @@ -821,6 +821,7 @@ ALTER TABLE users MODIFY COLUMN role ENUM('admin','director',...) NOT NULL; ### MySQL Compatibility Rules +- **Revision ids must be ≤ 32 characters.** Alembic's `alembic_version.version_num` column is `VARCHAR(32)`. A longer `revision = '...'` value passes `flask db upgrade`'s DDL step but fails when Alembic writes the version row (`Data too long for column 'version_num'`), often leaving the schema changed but the version un-recorded. The *filename* may be longer (e.g. `phase24_issue_created_notify_defaults.py`), but the `revision` id inside must be short (`phase24_notify_defaults`). Count before committing a new migration. - **`CREATE INDEX IF NOT EXISTS`** — not supported on MySQL < 8.0.12. Always use `INFORMATION_SCHEMA.STATISTICS` check first. - **`batch_alter_table`** — SQLite-only workaround; do not use for MySQL migrations. - **Migration deploy order:** Always run `flask db upgrade` before swapping `app/__init__.py` if the new version imports models that reference the new columns. diff --git a/migrations/versions/phase33_contract_notify_recipients.py b/migrations/versions/phase33_contract_recipients.py similarity index 97% rename from migrations/versions/phase33_contract_notify_recipients.py rename to migrations/versions/phase33_contract_recipients.py index 37773a0..d7dbd69 100644 --- a/migrations/versions/phase33_contract_notify_recipients.py +++ b/migrations/versions/phase33_contract_recipients.py @@ -7,7 +7,7 @@ the global NotificationMatrix routing, scoped to the contract's facilities. Uses INFORMATION_SCHEMA table-existence check — safe to re-run. """ -revision = 'phase33_contract_notify_recipients' +revision = 'phase33_contract_recipients' down_revision = 'phase32_device_token_columns' branch_labels = None depends_on = None