iDempiere DB (Diccionario + Migraciones)

Objetivo

Entregar cambios de DB/diccionario que:

• sean repetibles (dev/stage/prod),
• respeten convenciones iDempiere (EntityType, AD_Client/AD_Org, auditoria),
• tengan verificacion clara y plan de rollback.

Recordatorios iDempiere (para cambios estructurales)

• Objetos del plugin deben tener EntityType del plugin (no usar D/core).
• Tablas transaccionales suelen requerir columnas multi-tenant/auditoria: AD_Client_ID, AD_Org_ID, IsActive, Created, CreatedBy, Updated, UpdatedBy.
• Para cambios que impactan performance: definir indices y validar con EXPLAIN en consultas reales.

Workflow recomendado

1. Identificar el tipo de cambio
   • DDL (tabla/columna/index), metadata AD_*, data fix, o combinacion.
2. Definir compatibilidad
   • Version destino, si hay datos existentes, y estrategia sin downtime (si aplica).
3. Preparar migracion
   • Escribir scripts idempotentes cuando sea posible.
   • Incluir defaults/backfill para columnas nuevas si corresponde.
4. Verificar en DB limpia + DB con datos
   • Aplicar sobre una DB nueva.
   • Aplicar sobre un dump/backup representativo.
5. Validar en iDempiere
   • Revisar que el diccionario refleja el cambio y que la UI/proceso funciona.

SQL estructural para plugins con 2Pack

Cuando el cambio es para un plugin que usa el workflow de 2Pack COMIT SRL:

Ubicacion del DDL

• El DDL debe quedar en packages/system-<version>/sql/db_structure.sql
• Este archivo es la fuente primaria del SQL estructural instalable
• Se inyecta a SQLMandatory via script de sincronizacion

Flujo de trabajo

1. Escribir DDL en sql/db_structure.sql
2. Aplicar manualmente en base de desarrollo
3. Modelar metadata en Application Dictionary
4. Sincronizar SQLMandatory antes del build

Reglas importantes

• El PackOut.xml no es fuente primaria del DDL
• Un solo archivo db_structure.sql consolidado por version
• El DDL debe ser instalable desde cero (no solo deltas)
• Evitar SQL de soporte o correccion puntual en este archivo

Coordinacion

• Ver $idempiere-2pack para el flujo completo de desarrollo
• Los scripts de sincronizacion viven en utils_dev/2pack/

Checklist de salida

• [ ] Scripts o mecanismo de migracion definidos y repetibles.
• [ ] EntityType correcto para objetos del plugin.
• [ ] Probado en PostgreSQL (y en la DB objetivo del cliente si difiere).
• [ ] Documentado: upgrade, rollback y riesgos.
• [ ] Si es plugin con 2Pack: DDL en sql/db_structure.sql, no en PackOut.xml directo.