# Architecture Rules - Database Migration Rules # Rules for alembic/versions/*.py migration files # # NOTE: This project uses PostgreSQL only. SQLite is not supported. # PostgreSQL supports native ALTER TABLE operations, so batch_alter_table # is not required. These rules ensure migrations are clean and reversible. migration_rules: - id: "MIG-001" name: "Migrations should have meaningful downgrade functions" severity: "warning" description: | All migrations should have a proper downgrade() function that reverses the upgrade changes. This enables rolling back deployments and resetting development databases. WRONG: def downgrade() -> None: pass CORRECT: def downgrade() -> None: op.drop_column('users', 'email') pattern: file_pattern: "alembic/versions/**/*.py" check: "migration_has_downgrade" - id: "MIG-002" name: "Foreign keys must have explicit constraint names" severity: "error" description: | Foreign key constraints must have explicit names for easier debugging and consistent schema management. WRONG: op.create_foreign_key(None, 'other_table', ...) CORRECT: op.create_foreign_key('fk_table_column', 'other_table', ...) pattern: file_pattern: "alembic/versions/**/*.py" anti_patterns: - "create_foreign_key\\(None," - id: "MIG-003" name: "Indexes must have explicit names" severity: "warning" description: | Index names should be explicit for clarity and easier debugging. CORRECT: op.create_index('idx_users_email', 'users', ['email']) pattern: file_pattern: "alembic/versions/**/*.py" check: "migration_explicit_index_names" - id: "MIG-004" name: "Avoid batch_alter_table (not needed for PostgreSQL)" severity: "info" description: | This project uses PostgreSQL only. The batch_alter_table context manager is a SQLite workaround and is not needed for PostgreSQL. PostgreSQL supports native ALTER TABLE operations. pattern: file_pattern: "alembic/versions/**/*.py" note: "batch_alter_table is acceptable but unnecessary for PostgreSQL"