Server-tools: [RFC] base_elasticsearch

Hallo @lasley bei Akretion wir haben wahrscheinlich angefangen, was du brauchst:
https://github.com/akretion/connector-nosql
siehe auch den solr-Zweig https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
Bitte lassen Sie uns gemeinsam daran arbeiten. Wir haben bereits große Erfahrung mit der Integration von Odoo mit Solr- und Algolia-NoSQL-Datenspeichern.

Schön, danke @rvalyi - es sieht tatsächlich so aus, als hättest du angefangen, was ich brauche.

Leider ist eine der Anforderungen meines Projekts, dass es LGPL sein muss - ich hätte das im Nachhinein in meinem RFC erwähnen sollen (bearbeitet, um es aufzunehmen). Die LGPL-Anforderung schließt die Verwendung von connector und schließt auch die Einbeziehung dieser Logik in base_external_dbsource . Diese Anforderung ist auf meine geplante Verwendung dieses Moduls als Teil meiner Kern-SaaS-Abrechnungsinfrastruktur zurückzuführen.

Ich sehe hier viel Exportlogik, aber nichts zum Lesen der Daten. Liege ich mit dieser Einschätzung richtig?

Wie haben Sie die Notwendigkeit der Datenspeicherung in Odoo umgangen?

@lasley Ich bin der Autor für die Logik im base_external_dbsource . Ich habe mir die Geschichte angesehen und der einzige andere Originalbeitrag ist das Hinzufügen der Firebird-DB-Verbindungen. Wenn es wichtig ist, könnten wir erwägen, dieses Modul für LGPL neu zu lizenzieren.
Da es sich nur um technische Tools handelt, sehe ich kein Problem darin, dass das Server-Tools-Repository so viel LGPL wie möglich enthält.

@dreispt - Ich würde gerne die Logik zum vorhandenen Modul hinzufügen, wenn Sie mit der Relizenzierung gut sind. Ich werde diese Basis für die Erfassung von Metriken und die anschließende Abrechnung meiner SaaS-Angebote verwenden.

Am Anfang brauchen wir auch wirklich nur eine einfache Elastic-Verbindung, also passt base_external_dbsource . Ich würde es wahrscheinlich auch ein wenig umgestalten, um die if Ketten innerhalb von conn_open und execute loszuwerden, die exponentiell größer werden, wenn mehr Quellen hinzugefügt werden.

NoSQL ist in Bezug auf Abfragen etwas anders, aber ich kann mit ein wenig kreativer Anpassung immer noch in die execute Schnittstelle passen.

@lasley OK. Um alle anderen Beiträge zu respektieren, z. B. die Portierung von Versionen, eröffne ich ein Issue, um die Lizenzänderung vorzuschlagen und zu diskutieren.
Und wir sollten das Modul "pluggable" machen, wo die Unterstützung für zusätzliche Datenbanken, wie Firebird, durch ein zusätzliches Modul eingesteckt werden kann.

Danke @dreispt - sehr geschätzt!

Bezüglich der pluggable - Was haben Sie sich dabei gedacht? Mein geplantes Refactoring war eigentlich nur, um die beiden riesigen Wenn-Ketten zu durchbrechen, aber ich bin offen für andere Verbesserungen, solange sie auf meinem Entwicklerteller sind.

@lasley Ich meine, es einfach zu machen, um ein anderes Modul erweiterbar zu sein. Zusätzliche DB-Unterstützung könnte durch ein zusätzliches Erweiterungsmodul hinzugefügt werden.

@dreispt Ahhh ja gotcha. Bestimmt!

Irgendwelche Gedanken zu mir, alle unabhängigen Datenbankquellen in ihre eigenen Module zu zerlegen? Ich habe das Gefühl, dass dieses Versuch/Ausnahme-Ding oben etwas unhandlich ist, stimmst du zu? Dies ist die aktuelle Lösung , aber ich denke, sie könnte noch verbessert werden.

Ist das etwas, auf das wir wegen der stabilen Veröffentlichung auf v11 warten müssen? Oder ist die Freigabe zusammen mit einem Ersatzmodul(en) akzeptabel?

Ich denke auch, dass es vielleicht schön wäre, auch eine grundlegende CRUD-Typ-Schnittstelle hinzuzufügen, damit wir vielleicht daran denken könnten, von direktem SQL wegzukommen.

IMO wäre es für das Erweiterungsmodul sauberer, einfach den üblichen Gedanken zu machen: das base.external.dbsource Modell zu erben, um Funktionen und Modelle zu ändern.

Es ist sinnvoll, die DB-Provider für 10.0 zu extrahieren, da es sich um eine neue Version handelt, aber für 9.0 wird es wahrscheinlich nicht vernünftig sein - und ein Update würde bestehende Installationen zerstören.

10.0 ist jedoch bereits veröffentlicht und scheint eine 1:1-Migration zu sein. Ich denke, wir müssten bis 11 warten, um die Richtlinien für stabile Veröffentlichungen einzuhalten, oder?

Streng genommen ja.
Das bedeutet, dass wir keine Features aus dem aktuellen Modul entfernen sollten.

Was wäre, wenn wir die neuen Module in den niedrigeren Versionen automatisch installieren würden? Würde die Isolation erlauben, während ich hier bin, mit einem einfachen Ausschalter für später.

Die nach außen gerichtete API wird dieselbe sein, also denke ich, dass wir keine Probleme verursachen würden?

@lasley Ja, das ist eine gute Idee.

Hi,

@lasley Vielleicht möchten Sie sich https://github.com/camptocamp/odoo-elasticsearch-kibana ansehen

Grüße,

Joël

Im Anschluss an das, was @jgrandguillaume oben zeigt, besprechen wir einfach mit ihm, dass es großartig wäre, ein Tool wie https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor zu haben, um das Berichtsmodell zu definieren in Odoo, und dann die Daten für dieses Modell in ElasticSearch exportieren zu können, um es mit anderen Datenquellen zu kombinieren und dann mit Kibana darüber zu berichten.

Nun, ich bin mir nicht ganz sicher, ob dies der Ansatz ist, den @lasley bei diesem RFC verfolgt?

In beiderlei Hinsicht interessant, danke

Ist bi_view_editor dass @jbeficent die aktualisierte Form von sql_view verknüpft, die als Modulabhängigkeit für odoo-elasticsearch-kibana verknüpft ist?

Ich habe mit diesem RFC eine Art Mehrzweckabsicht. Die Hauptabsicht besteht darin, Statistiken aus Odoo zu verdrängen, ähnlich wie in beiden verlinkten Bibliotheken.

Etwas weiter unten muss ich einige der Datenpfade umkehren. Kibana ist eine großartige Visualisierung für mich, aber ich muss einige der Dashboards in Odoo erstellen, um direktes Reporting über Client-Dashboards zu ermöglichen.

@lasley Siehe bi_view_editor hier: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. Es ist derzeit keine Abhängigkeit für odoo-elasticsearch-kibana . Es ist ein Tool, das es einem normalen Benutzer ermöglicht, Odoo-Modelle für Berichtszwecke zu entwerfen. Ähnlich wie bei einem sql_view, aber die Macht liegt in der Hand des Benutzers.

Wir möchten auch Statistiken aus Odoo herausschieben, und das Ziel wäre, dass der Benutzer die Möglichkeit hat, zu entwerfen, welche Statistiken er aus Odoo exportieren möchte.

Rückweg wäre auch super.

@jbeficent - Nun, das ist in der Tat ziemlich cool. Aufgrund fehlender Beziehungen wäre es wahrscheinlich auch viel einfacher, so etwas für NoSQL zu erstellen.

Ich muss wahrscheinlich einige Methoden für Indizes in meine #645 einfügen, um so etwas zu unterstützen, was ein Konzept der Indexanalyse erfordern würde, das ich nicht entwickelt habe.

Ping an alle Interessierten - Ich habe ein vorläufiges Datendesign in https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 eingefügt, wenn jemand einen Blick darauf werfen möchte. Dem würde noch ein View-Framework fehlen, aber ich denke, es bringt uns vielleicht auf den richtigen Weg.