Persistencia¶

Datos de negocio en PostgreSQL: base única cortex; cada plugin posee sus tablas y migraciones.

Leyenda: Cuándo usar fixtures en memoria vs Postgres y tablas de plataforma. Actores: plugin, framework/database, platform_settings. Estado: Implementado (booking con Alembic).

flowchart TB
  subgraph dev [Desarrollo sin PG]
    Fix[fixtures JSON en memoria]
    MemStore["_STORE dict"]
  end
  subgraph prod [PostgreSQL cortex]
    Plat[platform_settings escalares]
    PlugTab["{plugin_id}_* tablas dominio"]
    Mig[cortex_migrations por plugin]
  end
  subgraph framework [Framework]
    URL[CORTEX_DATABASE_URL]
  end
  Fix --> MemStore
  URL --> Plat
  URL --> PlugTab
  PlugTab --> Mig

Cuándo usar¶

• Dejas fixtures JSON y necesitas datos reales.
• Implementas un plugin con SQLAlchemy y Alembic.
• Configuras settings de plataforma en PostgreSQL.

URL de base de datos¶

CORTEX_DATABASE_URL=postgresql+asyncpg://cortex:cortex@localhost:5432/cortex

El framework usa CORTEX_DATABASE_URL para toda la persistencia de plataforma (settings, control, plugins state).

Setup local¶

Script idempotente en el monorepo:

bash deploy/setup-postgres-local.sh

Crea rol cortex, base cortex, migraciones del plugin booking y tablas platform_settings / cortex_migrations.

Variables sugeridas en .env:

CORTEX_DATABASE_URL=postgresql+asyncpg://cortex:cortex@localhost:5432/cortex

Migración desde cortex¶

Si ya tenías la base anterior:

ALTER DATABASE cortex RENAME TO cortex;

Migraciones por plugin¶

Cada plugin con persistencia mantiene su propio alembic.ini y carpeta alembic/versions/.

Ejemplo (booking):

cd plugins/booking && uv run alembic upgrade head

Convención de tablas: prefijo {plugin_id}_ en schema public (ver ADR 017).

Orden sugerido de migraciones (grafo Reservas)¶

Ejecutar en CI/monorepo: scripts/run-plugin-migrations.sh (solo plugins presentes en el workspace).

Siguiente paso¶

• Settings — configuración por panel.
• ADR 007 — decisiones de arquitectura.