Server-tools: [RFC] base_elasticsearch

Bonjour @lasley chez Akretion, nous avons probablement commencé ce dont vous avez besoin :
https://github.com/akretion/connector-nosql
voir aussi la branche solr https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
s'il vous plaît, travaillons dessus ensemble. Nous avons déjà une grande expérience de l'intégration d'Odoo avec les magasins de données Solr et Algolia NoSQL.

Bien , merci

Malheureusement, l'une des exigences de mon projet est qu'il doit être LGPL - j'aurais dû le mentionner dans ma RFC avec le recul (édité pour l'inclure). L'exigence LGPL exclut l'utilisation de connector , et exclut également l'inclusion de cette logique dans base_external_dbsource . Cette exigence est due à mon utilisation planifiée de ce module dans le cadre de mon infrastructure de facturation SaaS de base.

Je vois beaucoup de logique d'exportation ici, mais rien pour lire les données. Ai-je raison dans cette évaluation?

Comment avez-vous contourné le besoin de stocker des données dans Odoo ?

@lasley Je suis l'auteur de la logique du base_external_dbsource . J'ai regardé l'historique et la seule autre contribution originale est l'ajout des connexions Firebird DB. Si c'est important, nous pourrions envisager de reconvertir ce module en LGPL.
En fait, puisqu'il ne s'agit que d'outils techniques, je ne verrais pas de problème pour que le référentiel server-tools soit autant que possible en LGPL.

@dreispt - J'aimerais ajouter la logique au module existant si vous êtes bon avec la relicense. Je vais utiliser cette base pour l'ingestion de métriques et la facturation ultérieure de mes offres SaaS, donc ne pas permettre à l'AGPL d'y pénétrer est un bloqueur absolu.

Au début, une simple connexion Elastic est vraiment tout ce dont nous avons besoin aussi, donc base_external_dbsource convient. Je le remanierais probablement un peu pour me débarrasser des chaînes if à l'intérieur de conn_open et execute qui deviendront exponentiellement plus grandes à mesure que de nouvelles sources commenceront à être ajoutées.

NoSQL est un peu différent en termes de requête, mais je peux toujours m'intégrer dans l'interface execute avec un peu d'adaptation créative.

@lasley OK. Pour respecter toutes les autres contributions, comme le portage de versions, j'ouvrirai un Issue pour proposer et discuter du changement de licence.
Et nous devrions rendre le module "pluggable", où le support de bases de données supplémentaires, comme Firebird, peut être branché par un module supplémentaire.

Merci @dreispt - très apprécié !

Concernant le pluggable - Qu'aviez-vous en tête ? Ma refactorisation prévue était vraiment juste pour casser les deux chaînes si géantes, mais je suis ouvert à d'autres améliorations tant que c'est sur ma plaque de développement.

@lasley Je veux dire qu'il est facile d'être extensible par un autre module. Un support de base de données supplémentaire pourrait être ajouté par un module d'extension supplémentaire.

@dreispt Ahhh oui gotcha. Absolument!

Avez-vous des idées pour supprimer toutes les sources de bases de données indépendantes dans leurs propres modules ? J'ai l'impression que cette chose d'essai/sauf en haut est un peu lourde, êtes-vous d'accord ? C'est la solution actuelle , mais je pense qu'elle pourrait encore être améliorée.

Est-ce quelque chose que nous devons attendre jusqu'à la v11 car une version stable ? Ou est-ce que la sortie avec un ou plusieurs modules de remplacement est acceptable ?

Je pense aussi qu'il serait peut-être bien d'ajouter une interface de base de type CRUD afin que nous puissions peut-être penser à s'éloigner du SQL direct.

IMO, il serait plus propre pour le module d'extension de simplement faire la réflexion habituelle : hériter du modèle base.external.dbsource pour modifier les fonctionnalités et les modèles.

Il est raisonnable d'extraire les fournisseurs de base de données pour 10.0, car il s'agit d'une nouvelle version, mais ce ne sera probablement pas raisonnable pour 9.0 - et la mise à jour casserait les installations existantes.

10.0 est déjà publié et semble être une migration 1:1. Je pense que nous devrons attendre jusqu'au 11 pour adhérer à la politique de publication stable, n'est-ce pas ?

A strictement parler oui.
Cela signifie que nous ne devons pas supprimer de fonctionnalités du module actuel.

Et si nous faisions l'installation automatique des nouveaux modules dans les versions inférieures ? Permettrait l'isolement pendant que je suis ici, avec un interrupteur facile pour plus tard.

L'API externe sera la même, donc je ne pense pas que nous causerions de problèmes ?

@lasley Oui, c'est une bonne idée.

Salut,

@lasley Peut-être que vous voulez regarder https://github.com/camptocamp/odoo-elasticsearch-kibana

Salutations,

Joël

Suite à ce que @jgrandguillaume montre ci-dessus, nous discutons simplement avec lui que ce qui serait formidable serait d'avoir un outil comme https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor pour définir le modèle de reporting dans Odoo, puis de pouvoir exporter les données de ce modèle dans ElasticSearch, afin qu'il puisse être combiné avec d'autres sources de données, puis en faire rapport à l'aide de Kibana.

Maintenant, je ne sais pas exactement si c'est l'approche que @lasley suit sur cette RFC ?

Intéressant sur les deux plans , merci

Est-ce que bi_view_editor que @jbeficent a lié la forme mise à jour du sql_view qui est lié en tant que dépendance de module pour odoo-elasticsearch-kibana ?

J'ai une sorte d'intention polyvalente avec cette RFC. L'intention principale est de sortir les statistiques d'Odoo, de la même manière que ce qui est fait dans les deux bibliothèques liées.

Un peu plus loin, je vais devoir inverser certains des chemins de données. Kibana est un excellent visualiseur pour moi, mais je devrai créer certains des tableaux de bord dans Odoo pour un reporting direct via les tableaux de bord client.

@lasley Voir bi_view_editor ici : https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. Ce n'est pas actuellement une dépendance pour odoo-elasticsearch-kibana . C'est un outil qui permet à un utilisateur normal de concevoir des modèles Odoo à des fins de reporting. Similaire à faire un sql_view, mais le pouvoir est entre les mains de l'utilisateur.

Nous souhaitons également extraire les statistiques d'Odoo, et l'objectif serait que l'utilisateur ait la possibilité de concevoir les statistiques qu'il souhaite exporter depuis Odoo.

Le chemin inverse serait également génial.

@jbeficent - Eh bien, c'est plutôt cool. Créer quelque chose comme ça pour NoSQL serait probablement beaucoup plus facile aussi en raison du manque de relations.

J'ai probablement besoin d'ajouter des méthodes pour les index dans mon #645 afin de prendre en charge quelque chose comme ça, qui nécessiterait un concept d'analyse d'index que je n'ai pas développé.

Ping à toute personne intéressée - j'ai mis une conception de données préliminaire dans https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 si quelqu'un veut jeter un œil. Il manquerait encore un cadre de vue, mais je pense que cela nous met peut-être sur la bonne voie.