General

¡Bienvenido a los foros Aeodoo!

Somos la comunidad de Odoo internacional hispanohablante.
Estos foros son para compartir y debatir dudas técnicas, funcionales y mejores prácticas para Odoo. Recuerda que no están permitidos los insultos, descalificaciones o spam, cualquier conducta reprobable supondrá el baneo del usuario.

0

Odoo upgrade service (enterprise) VS OpenUpgrade

Avatar
Ignacio Rodriguez

Hola a todos, os deseo un muy feliz 2023.


Lanzo esta consulta para implantadores que seais partner de Odoo y tengáis clientes en enterprise.

Como bien sabréis, Odoo proporciona el upgrade de versiones mayores para clientes que tengan una suscripción enterprise. Esta actualización de versión mayor se ejecuta en los servidores de Odoo mediante scripts propietarios.

El problema de este upgrade es que solo actualiza la base de datos para el core (CE) y los addons de enterprise. Todas aquellas tablas o campos de los módulos de OCA quedan inalterados.

Por otra parte, los scripts de migración de los módulos de OCA confían en que el upgrade se haya realizado vía OpenUpgrade y no a través de ese servicio de actualización propietario de Odoo.

¿Cómo contempláis este tipo de escenarios con vuestros clientes?

Para centrar el problema que tengo. Tenemos un Odoo enterprise en V12 que queremos subir a V13 (y posiblemente hacia 14 ó 15 a continuación). Si solicitamos a Odoo la base de datos en V13, nos la devuelve, pero varios módulos de OCA (por ejemplo account_asset_management) esperan que haya campos en account.move.line (por ejemplo old_invoice_id, ver aquí: https://github.com/OCA/account-financial-tools/blob/13.0/account_asset_management/migrations/13.0.1.0.0/post-migration.py#L10 ), campos que crea OpenUpgrade en la migración del módulo account de V12 a V13. Por lo tanto, la actualización de estos módulos de OCA falla irremediablemente si se emplea esa base de datos devuelta por Odoo.

Si, por el contrario, lanzo la migración de 12 a 13 con OpenUpgrade, hay determinados modelos de datos exclusivos de enterprise (por ejemplo el módulo Documents) que también necesitan scripts de actualización porque hay estructuras de datos que cambian de 12 a 13. Por ejemplo, la tabla document_tag_rel cambia el nombre de la columna ir_attachment_id a documents_document_id. 

¿Cómo contempláis este tipo de problemas en donde hay cambios en la estructura de datos tanto de enterprise como de OCA para aseguraros de que todo quede bien afinado?

Seguiré peleándome por mi parte, si bien agradecería algún feedback o pista por dónde pueden ir los tiros.

Muchas gracias!

Ignacio
1 Comment
Avatar
Discard

Hola,

Como bien has dicho OpenUpgrade ignora los Enteprise, y la migración Enterprise ignora los de OCA. Al final no hay método que te haga ambos.

Nosotros usamos la migración enterprise y nos hemos creado nuestro propio sistema que convierte los datos de los módulos OCA. Pero podría ser igual al revés migrar con OpenUpgrade y crear tu propio sistema para adaptar los enteprise.

En ambos casos vas a tener que crear un sistema que te permita adaptar lo que no migra uno de los sistemas, ya sea usando comandos SQL o utilizando el XML-RPC. Este el reto de usar híbridos Enterprise con OCA, son una solución muy buena pero a la hora de migrar tienes este problema.

Saludos,
Ignacio

El 4/1/23 a las 21:54, Ignacio Rodriguez escribió:

Una nueva pregunta Odoo upgrade service (enterprise) VS OpenUpgrade de General se ha publicado. Haga clic aquí para acceder a la pregunta:

Ver pregunta


Enviado por Asociación Española de Odoo usando Odoo.

--
Ignacio Ibeas
Acysos S.L. (www.acysos.com)
Odoo Partner (https://www.odoo.com/es_ES/partners/acysos-s-l-80090)
Asociado Asociación Española de Odoo (https://www.aeodoo.org/members/acysos-s-l-24)
Odoo Community Association (https://odoo-community.org/members/acysos-s-l-ignacio-ibeas-760)
Github (http://www.github.com/acysos)
Odoo Apps (https://www.odoo.com/apps/modules/browse?author=Acysos S.L.)
C/ Miguel Astrain 18, 1º Oficina A
31006 Pamplona, Navarra.
ignacio@acysos.com
Tel. 948238905
---------------------- // -------------------
La información contenida en este mensaje de correo electrónico es
confidencial, para ser leída por la(s) persona(s) a quién se dirige. El
acceso a este mensaje por otras personas no está autorizado. Si Ud. no es la
persona a la que va dirigido, cualquier divulgación, copia o distribución de
la información queda prohibida y puede ser ilegal. Asimismo, cualquier acción
tomada o dejada de tomar basada en la información contenida en este mensaje
queda prohibida y puede ser ilegal.
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone is
unauthorised. If you are not the intended recipient, any disclousure,
copying, distribuition or any action taken or omited to be taken in reliance
on it, is prohibited and may be unlawful.
2 Answers
1
Avatar
Pedro M. Baeza
Best Answer

Ignacio ya ha dado las pautas principales, y el resumen es que no existe "solución buena", y es lo que ha creado Odoo con esta dualidad.

Mi estrategia es la contraria (OpenUpgrade), eso sí, por las siguientes razones:

- El servicio de migración enterprise es una caja negra, de la que luego hay que hacer "ingeniería inversa" para saber cómo deja los datos para ser utilizados en el resto de módulos OCA.

- También el mismo hace a veces "limpieza de más", eliminando columnas, campos, etc, de los que otros módulos OCA se estaban beneficiando para no perder información.

- Como OpenUpgrade es parte de OCA y los implicados en su desarrollo utilizamos módulos OCA, la fusión de módulos, renombramientos, etc están incluidos en el propio OpenUpgrade (ejemplo: https://github.com/OCA/OpenUpgrade/blob/14.0/openupgrade_scripts/apriori.py ), y no hay que duplicar esfuerzos o hacer cosas raras post-upgrade.

- Siendo uno de los desarrolladores de OpenUpgrade, también he visto que nos esmeramos más en cierto pulido de detalles que el servicio enterprise. Ejemplo: nuestro mecanismo para v12 para convertir los fragmentos HTML de Bootstrap 3 a Bootstrap 4 que Odoo no tuvo en cuenta. Y en v16 pasará lo mismo con BS4 a BS5.

- Esto alguno lo puede ver como una desventaja, pero en realidad no lo es, y es que con OpenUpgrade, hay que pasar por cada versión intermedia. ¿Por qué no lo considero una desventaja? Porque eso permite ir aplicando cada transformación de las versiones intermedias de los módulos OCA. Esto no significa que haya que tener todos los módulos de tu BD migrados a cada una de las versiones intermedias, ojo. Simplemente, que si hay módulos OCA migrados a esas versiones y tienen scripts de migración, los incluyes en tu addons_path y se ejecutan para llegar al resultado final esperado. En cambio, con migraciones enterprise, se obtiene la BD en la versión final, y realizar las transformaciones intermedias puede ser una locura, y tantas variaciones como versión inicial y final haya.

- En OpenUpgrade intentamos mantener una política de eficiencia suficiente para tener las migraciones terminadas en un tiempo razonable, pero dejamos que muchas cosas se procesen en ORM por completitud. El servicio de enterprise realiza todo en SQL puro, lo que es más eficiente, pero te puedes encontrar con campos no rellenados que luego sean problemáticos.

- Como OpenUpgrade se ejecuta en local, es más fácil de instrumentar e incrustar en un pipeline completo de cara a la migración definitiva, aunque todo sea dicho, el servicio enterprise también dispone de API.

Por último, la principal desventaja que puede haber con OpenUpgrade es la disponibilidad de los scripts, que históricamente siempre ha ido por detrás que la de enterprise, aunque bueno, llevan prometiendo varios años migración a la última versión en el mismo momento de la salida de la misma, y de momento no lo han conseguido, y creo que el servicio de migración a 16.0 todavía sigue en beta.

Mis consejos:

- Como ya se ha dicho a lo largo del hilo, utiliza OpenUpgrade.

- Reduce al máximo el número de módulos enterprise utilizados. Hay muchos módulos OCA que son equivalentes.

- Nunca uses ni permitas usar Odoo Studio. Eso del código como datos te va a traer muchos dolores de cabeza.

1 Comment
Avatar
Discard
Avatar
Ignacio Rodriguez
-

Muchísimas gracias Pedro por la explicación tan detallada. Finalmente he logrado, tras muchas horas de desvelo estos días, migrar de V12 enterprise a V14 enterprise, empleando OpenUpgrade. He decidido optar por Open Upgrade porque, por una cuestión de pura proporción en la cantidad de código (Enterprise VS CE/OCA), es más sencillo detectar qué cambia Enterprise en sus modelos de datos exclusivos y actuar en consecuencia elaborando los scripts SQL necesarios para esa capa enterprise. Gracias por los consejos a los dos (Ignacio y Pedro).

0
Avatar
Ignacio Rodriguez
Best Answer

Muchas gracias Ignacio. A pelearse, poco a poco se va viendo la luz...

Avatar
Discard

Your Answer

Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!