Server-tools: [RFC] base_elasticsearch

Hola @lasley en Akretion, probablemente comenzamos lo que necesita:
https://github.com/akretion/connector-nosql
también vea la rama solr https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
por favor, trabajemos juntos en esto. Ya tenemos una gran experiencia en la integración de Odoo con almacenes de datos NoSQL de Solr y Algolia.

Bien , gracias

Desafortunadamente, uno de los requisitos de mi proyecto es que tiene que ser LGPL; debería haberlo mencionado en mi RFC en retrospectiva (editado para incluirlo). El requisito de LGPL descarta el uso de connector y también descarta la inclusión de esta lógica en base_external_dbsource . Este requisito se debe al uso planificado de este módulo como parte de mi infraestructura central de facturación de SaaS.

Veo mucha lógica de exportación aquí, pero nada para leer los datos. ¿Estoy en lo cierto en esa evaluación?

¿Cómo evitó la necesidad de almacenar datos en Odoo?

@lasley Soy el autor de la lógica en base_external_dbsource . Miré la historia y la única otra contribución original es agregar las conexiones Firebird DB. Si es importante, podríamos considerar volver a otorgar la licencia de ese módulo a LGPL.
De hecho, dado que son solo herramientas técnicas, no vería ningún problema para que el repositorio de herramientas de servidor sea lo más LGPL posible.

@dreispt : me encantaría agregar la lógica al módulo existente si eres bueno con la nueva licencia. Voy a utilizar esta base para la ingestión de métricas y la facturación posterior de mis ofertas de SaaS, por lo que no permitir que AGPL penetre en eso es un bloqueo absoluto.

Al principio, una conexión elástica simple es realmente todo lo que necesitamos también, por lo que base_external_dbsource encaja. También es probable que lo refactorice un poco para deshacerme de las cadenas if dentro de conn_open y execute que se volverán exponencialmente más grandes a medida que se comiencen a agregar más fuentes.

NoSQL es un poco diferente en términos de consultas, pero aún puedo encajar en la interfaz execute con un poco de adaptación creativa.

@lasley OK. Para respetar todas las demás contribuciones, como la migración de versiones, abriré un problema para proponer y discutir el cambio de licencia.
Y deberíamos hacer que el módulo sea "conectable", donde el soporte para bases de datos adicionales, como Firebird, puede ser conectado por un módulo adicional.

Gracias @dreispt - ¡muy apreciado!

Respecto al pluggable - ¿Qué tenías en mente? Mi refactorización planeada era realmente solo romper las dos cadenas gigantes de if, pero estoy abierto a otras mejoras mientras está en mi plato de desarrollo.

@lasley Me refiero a facilitar la ampliación mediante otro módulo. Se podría agregar soporte db adicional mediante un módulo de extensión adicional.

@dreispt Ahhh sí lo

¿Alguna idea de que elimine todas las fuentes de bases de datos independientes en sus propios módulos? Siento que este intento / excepción en la parte superior es un poco difícil de manejar, ¿estás de acuerdo? Esta es la solución actual , pero creo que aún podría mejorarse.

¿Es esto algo por lo que tenemos que esperar a la v11 porque es una versión estable? ¿O es aceptable la publicación junto con un módulo o módulos de reemplazo?

También creo que tal vez sería bueno agregar una interfaz básica de tipo CRUD para que tal vez podamos pensar en alejarnos del SQL directo.

En mi opinión, sería más limpio para el módulo de extensión simplemente hacer lo habitual: heredar el modelo base.external.dbsource para modificar características y modelos.

Es razonable extraer los proveedores de db para 10.0, ya que es una versión nueva, pero probablemente no sea razonable para 9.0, y la actualización rompería las instalaciones existentes.

Sin embargo, 10.0 ya se lanzó y parece ser una migración 1: 1. Creo que tendríamos que esperar hasta las 11 para cumplir con la política de lanzamiento estable, ¿verdad?

Estrictamente hablando, sí.
Eso significa que no deberíamos eliminar funciones del módulo actual.

¿Qué pasa si hacemos que los nuevos módulos se instalen automáticamente en las versiones inferiores? Permitiría el aislamiento mientras estoy aquí, con un interruptor de apagado fácil para más tarde.

La API externa será la misma, por lo que no creo que causemos ningún problema.

@lasley Sí, es una buena idea.

Hola,

@lasley Puede que quieras ver https://github.com/camptocamp/odoo-elasticsearch-kibana

Saludos,

Joël

Siguiendo con lo que @jgrandguillaume muestra arriba, solo discutimos con él que lo que sería genial sería tener una herramienta como https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor para definir el modelo de informes. en Odoo, y luego poder exportar los datos para este modelo a ElasticSearch, de modo que se pueda combinar con otras fuentes de datos y luego informar sobre él usando Kibana.

Ahora, no estoy exactamente seguro de si este es el enfoque que está siguiendo @lasley en este RFC.

Interesante en ambos aspectos, gracias @jgrandguillaume & @jbeficent.

¿Es bi_view_editor que @jbeficent vinculó la forma actualizada del sql_view que está vinculado como una dependencia de módulo para odoo-elasticsearch-kibana ?

Tengo una especie de intención multipropósito con este RFC. La intención principal es sacar las estadísticas de Odoo, similar a lo que se está haciendo en ambas bibliotecas vinculadas.

Un poco más adelante, tendré que revertir algunas de las rutas de datos. Kibana es un gran visualizador para mí, pero tendré que crear algunos de los paneles en Odoo para generar informes directos a través de los paneles del cliente.

@lasley Vea bi_view_editor aquí: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. Actualmente no es una dependencia para odoo-elasticsearch-kibana . Es una herramienta que permite a un usuario normal diseñar modelos Odoo con fines de generación de informes. Similar a hacer sql_view, pero el poder está en la mano del usuario.

También queremos sacar las estadísticas de Odoo, y el objetivo sería que el usuario tenga la capacidad de diseñar las estadísticas que le gustaría exportar desde Odoo.

El camino inverso también sería genial.

@jbeficent - Bueno, eso es realmente genial. Crear algo como esto para NoSQL probablemente también sería mucho más fácil debido a la falta de relaciones.

Probablemente necesite agregar algunos métodos para índices en mi # 645 para respaldar algo como esto, que necesitaría un concepto de análisis de índice que no desarrollé.

Haga ping a cualquier persona interesada: puse un diseño de datos preliminar en https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 si alguien quiere echar un vistazo. Esto todavía carecería de un marco de vista, pero creo que tal vez nos ponga en el camino correcto.