Samir Boulahtit
3614d448e4
Database & Migrations: - Update all Alembic migrations for PostgreSQL compatibility - Remove SQLite-specific syntax (AUTOINCREMENT, etc.) - Add database utility helpers for PostgreSQL operations - Fix services to use PostgreSQL-compatible queries Documentation: - Add comprehensive Docker deployment guide - Add production deployment documentation - Add infrastructure architecture documentation - Update database setup guide for PostgreSQL-only - Expand troubleshooting guide Architecture & Validation: - Add migration.yaml rules for SQL compatibility checking - Enhance validate_architecture.py with migration validation - Update architecture rules to validate Alembic migrations Development: - Fix duplicate install-all target in Makefile - Add Celery/Redis validation to install.py script - Add docker-compose.test.yml for CI testing - Add squash_migrations.py utility script - Update tests for PostgreSQL compatibility - Improve test fixtures in conftest.py Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
69 lines
2.2 KiB
YAML
69 lines
2.2 KiB
YAML
# 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"
|