Persistencia¶
Datos de negocio por tenant en PostgreSQL: una base cortex_{tenant} por inquilino; cada plugin posee sus tablas y migraciones.
Cuándo usar¶
- Dejas fixtures JSON y necesitas datos reales.
- Implementas un plugin con SQLAlchemy y Alembic.
- Configuras settings de plataforma en PostgreSQL.
URL por tenant¶
CORTEX_DATABASE_URL_TEMPLATE=postgresql+asyncpg://cortex:cortex@localhost:5432/cortex_{tenant}
CORTEX_DEFAULT_TENANT=default
El framework resuelve la URL según header X-Tenant-Id.
Setup local¶
Script idempotente en el monorepo:
Crea rol cortex, base cortex_default, migraciones del plugin booking y tablas tenant_settings / cortex_migrations.
Variables sugeridas en .env:
Migraciones por plugin¶
Cada plugin con persistencia mantiene su propio alembic.ini y carpeta alembic/versions/.
Ejemplo (booking):
Convención de tablas: prefijo del dominio (booking_resources, booking_bookings).
Provisioning de tenant¶
TenantProvisioner orquesta crear BD y ejecutar migraciones de plugins habilitados. Hoy las funciones de creación de BD y Alembic son inyectables; el script deploy/setup-postgres-local.sh cubre desarrollo local.
Tabla de control: cortex_migrations (plugin_id, revision, applied_at).
Ownership¶
| Capa | Responsabilidad |
|---|---|
| Framework | URL por tenant, settings globales, orquestación |
| Plugin | Modelos, alembic/, seeds de dev |
Los plugins no comparten esquema entre sí salvo tablas del framework (tenant_settings, cortex_migrations).
Siguiente paso¶
Ciclo de vida — cuándo corre el provisioning vs las peticiones API.