plantillas-proyectos/docs/SCHEMA_A76_UPDATE.md

Actualización de Schemas A76

Fecha de actualización: 5 de noviembre de 2025

---

✅ Modelos Actualizados al Schema A76

Se han actualizado todos los modelos en api/v1/modules/a76/ para usar el schema a76 en PostgreSQL.

📋 Tablas Configuradas

Módulo	Tabla	Schema	Estado
Company	gcompany	a76	✅ Actualizada
Client & Provider	client_provider	a76	✅ Actualizada
Client & Provider	gclient_provider_address	a76	✅ Actualizada
Client & Provider	gclient_provider_programs	a76	✅ Actualizada
GParts	parts	a76	✅ Actualizada
Class	classes	a76	✅ Actualizada
Licenses	licenses	a76	✅ Ya estaba
Licenses	license_usage	a76	✅ Ya estaba
Tenants	tenants	a76	✅ Ya estaba

🔄 Cambios Realizados

1. Configuración de Schema

# ANTES
class GCompany(Base):
    __tablename__ = "gcompany"

# DESPUÉS  
class GCompany(Base):
    __tablename__ = "gcompany"
    __table_args__ = {"schema": "a76"}

2. Foreign Keys Actualizadas

# ANTES
client_id = Column(String(8), ForeignKey('client_provider.client_id'), ...)

# DESPUÉS
client_id = Column(String(8), ForeignKey('a76.client_provider.client_id'), ...)

🏗️ Estructura de Schemas

PostgreSQL Database
├── Schema: public
│   ├── countries
│   ├── currency_types  
│   ├── material_types
│   └── ... (reference data)
│
└── Schema: a76
    ├── tenants
    ├── licenses
    ├── license_usage
    ├── gcompany
    ├── client_provider
    ├── gclient_provider_address
    ├── gclient_provider_programs
    ├── parts
    └── classes

🔗 Relaciones Mantenidas

Las relaciones entre schemas funcionan correctamente:

• A76 → Public: Los modelos A76 pueden referenciar datos de referencia en public
• A76 → A76: Las relaciones internas del schema A76 están actualizadas
• Composite Keys: Las relaciones con claves compuestas funcionan correctamente

Ejemplos de Relaciones Cross-Schema:

# Part (a76) → Country (public)
country_of_origin = Column(String(3), ForeignKey('public.countries.m3_key'))

# Part (a76) → CurrencyType (public) 
currency_key = Column(String(3), ForeignKey('public.currency_types.code'))

# Class (a76) → MaterialType (public)
material_key = Column(String(10), ForeignKey('public.material_types.key'))

🎯 Beneficios de la Separación

1. Organización: Datos de negocio separados de datos de referencia
2. Seguridad: Permisos granulares por schema
3. Mantenimiento: Facilita respaldos y migraciones selectivas
4. Escalabilidad: Permite distribuir schemas en el futuro
5. Claridad: Separación lógica de responsabilidades

⚠️ Consideraciones Importantes

1. Migraciones: Las nuevas migraciones deben especificar el schema a76
2. Permisos DB: El usuario de base de datos necesita permisos en ambos schemas
3. Testing: Los tests deben considerar la estructura de schemas
4. Backup: Configurar respaldos para incluir ambos schemas

📝 Próximos Pasos

1. Crear migraciones de Alembic con el schema correcto
2. Verificar permisos de base de datos para el usuario de aplicación
3. Actualizar tests para considerar la estructura de schemas
4. Documentar convenciones de naming para futuros modelos

---

🔧 Comando de Verificación

Para verificar que todos los modelos tienen el schema correcto:

grep -r "__table_args__ = {\"schema\": \"a76\"}" backend/api/v1/modules/a76/*/models.py

Resultado esperado: 8 coincidencias (una por cada modelo A76)

---

Actualización completada el 5 de noviembre de 2025