Ir al contenido

Refactorización del framework EDI en OCA

Separación de dependencias

En la OCA se ha aprobado recientemente un cambio importante en el repositorio edi-framework (PR #192) que aporta una mejora significativa en la forma en que se gestionan las dependencias dentro del ecosistema EDI de Odoo.

El problema hasta ahora

Hasta este cambio, el módulo edi_oca tenía como dependencias directas tanto queue_job como component. Esto, en la práctica, generaba varios inconvenientes:

  • Sobrecarga innecesaria: incluso en proyectos donde no se requería ni el sistema de colas de trabajos (queue_job) ni el framework de componentes, era obligatorio instalar estos módulos.
  • Mayor complejidad: al obligar a tener un stack de dependencias más amplio, aumentaban los riesgos de conflictos y las dificultades en actualizaciones.
  • Menor flexibilidad: todos los proyectos necesitaban una base compleja para funcionar.

La solución propuesta

El PR introduce una separación clara entre la funcionalidad base y los comportamientos opcionales:

  • edi_core_oca → Proporciona el núcleo del framework, sin dependencias externas pesadas.
  • edi_component_oca → Aporta la integración con el sistema component, de manera aislada.
  • edi_queue_oca → Añade el soporte de queue_job, encapsulado en un módulo propio.

De esta forma, el framework se convierte en una base modular, sobre la que cada proyecto puede decidir qué piezas adicionales necesita.

Detalles técnicos relevantes

  • Se han definido hooks para gestionar correctamente la transición y asegurar que los módulos adicionales puedan engancharse sin romper compatibilidad.
  • Se ha regenerado el fichero de xml_ids para mantener coherencia con las referencias internas y facilitar las migraciones.
  • La estructura resultante está ya pensada para encajar en la transición hacia Odoo 19, pero sigue siendo plenamente compatible con Odoo 18.

Beneficios

  1. Modularidad real: cada instalación de EDI solo carga lo estrictamente necesario.
  2. Compatibilidad hacia adelante: se simplifica la adaptación a nuevas versiones de Odoo.
  3. Mantenibilidad: menos dependencias obligatorias implican menos posibles conflictos.
  4. Flexibilidad para integradores: no todos los proyectos EDI requieren colas de trabajos ni el sistema de componentes, y ahora es posible escoger.

Conclusión

Este cambio puede parecer pequeño a nivel de código, pero su impacto en el día a día es grande: supone una mejora en la arquitectura del framework EDI de la OCA, lo hace más ligero y adaptable, y prepara el terreno para futuras evoluciones.

Un paso más hacia un ecosistema más limpio, modular y sostenible en Odoo.

Cuando confiar o no en la IA para implantar tu ERP
Un uso responsable de la inteligencia artificial.