Server-tools: [RFC] base_elasticsearch

Akretionの@lasleyこんにちは、私たちはおそらくあなたが必要なものを始めました：
https://github.com/akretion/connector-nosql
solrブランチhttps://github.com/akretion/connector-nosql/tree/9.0-solrも参照して
cc @sebastienbeau
一緒に取り組んでいきましょう。 OdooをSolrおよびAlgoliaNoSQLデータストアと統合した素晴らしい経験がすでにあります。

いいですね、 ます-確かにあなたが私が必要なものを始めたように見えます。

残念ながら、私のプロジェクトの要件の1つは、それがLGPLでなければならないということです-後から考えると、RFCでそのことを言及する必要がありました（それを含めるように編集されています）。 LGPL要件は、 connectorの使用を除外し、このロジックをbase_external_dbsource含めることも除外します。 この要件は、コアSaaS課金インフラストラクチャの一部としてこのモジュールを計画的に使用しているためです。

ここには多くのエクスポートロジックがありますが、データを読み取るためのものはありません。 私はその評価で正しいですか？

Odooにデータを保存する必要性をどのように回避しましたか？

@lasley私はbase_external_dbsourceのロジックの作成者です。 私は歴史を調べましたが、他の唯一の元々の貢献はFirebirdDB接続の追加です。 重要な場合は、そのモジュールをLGPLに再ライセンスすることを検討できます。
実際、これらは単なる技術ツールであるため、サーバーツールリポジトリが可能な限りLGPLであることに問題はないと思います。

@ dreispt-再ライセンスに問題がなければ、既存のモジュールにロジックを追加したいと思います。 このベースをメトリックの取り込みとその後のSaaSオファリングの請求に使用するので、AGPLがそこに浸透しないようにすることは絶対的なブロッカーです。

最初は、単純なElastic接続だけで十分なので、 base_external_dbsource適しています。 また、ソースが追加され始めると指数関数的に大きくなるconn_openとexecute内のifチェーンを取り除くために、少しリファクタリングする可能性があります。

NoSQLはクエリの点で少し異なりますが、少し創造的な適応を行うことで、 executeインターフェイスに適合させることができます。

@lasleyOK 。 バージョンからの移植など、他のすべての貢献を尊重するために、ライセンスの変更を提案して議論するために問題を開きます。
また、モジュールを「プラグ可能」にして、Firebirdなどの追加データベースへのサポートを追加モジュールでプラグインできるようにする必要があります。

ありがとう@ dreispt-大いに感謝します！

pluggable -何を考えていましたか？ 私の計画したリファクタリングは、実際には2つの巨大なifチェーンを分割することでしたが、開発プレート上にある間は、他の改善を受け入れることができます。

@lasleyつまり、別のモジュールで簡単に拡張できるようにすることです。 追加のdbサポートは、追加の拡張モジュールによって追加できます。

@dreisptああ、そうだね。 間違いなく！

独立したデータベースソースをすべて独自のモジュールに分解することについて何か考えはありますか？ 一番上にあるものを除いて、この試みは少し扱いに​​くいように感じます、あなたは同意しますか？ これは現在の解決策ですが、それでも改善できると思います。

安定したリリースのため、これはv11まで待たなければならないものですか？ または、交換用モジュールと一緒にリリースすることは許容されますか？

また、基本的なCRUDタイプのインターフェイスも追加して、直接SQLからの移行を検討できるようにするとよいと思います。

IMOは、拡張モジュールが通常の考え方を実行する方がクリーンです。 base.external.dbsourceモデルを継承して、機能とモデルを変更します。

新しいバージョンであるため、10.0のdbプロバイダーを抽出することは合理的ですが、9.0ではおそらく合理的ではなく、更新すると既存のインストールが破損します。

10.0はすでにリリースされていますが、1：1の移行のようです。 安定したリリースポリシーを順守するには、11時まで待たなければならないと思いますよね？

厳密に言えばそうです。
つまり、現在のモジュールから機能を削除するべきではありません。

新しいモジュールを下位バージョンで自動インストールした場合はどうなりますか？ 私がここにいる間は隔離が可能で、後で簡単にオフにすることができます。

外向きのAPIは同じなので、問題はないと思いますか？

@lasleyはい、それは良い考えです。

やあ、

@lasleyhttps ：//github.com/camptocamp/odoo-elasticsearch-kibanaを見たいと思うかもしれません

よろしく、

ジョエル

@jgrandguillaumeが上に示したものに続いて、レポートモデルを定義するためのhttps://github.com/OCA/reporting-engine/tree/8.0/bi_view_editorのようなツールがあれば素晴らしいと彼と話し合い

さて、これが@lasleyがこのRFCで従うアプローチであるかどうかは正確には

両方の点で興味深いです、 @ jgrandguillaumeと@jbeficentに感謝します。

されるbi_view_editor @jbeficentはのアップグレードされたフォームリンクされていることsql_viewのためのモジュールの依存関係としてリンクされているodoo-elasticsearch-kibana ？

私はこのRFCで一種の多目的な意図を持っています。 主な目的は、リンクされた両方のライブラリで行われていることと同様に、統計をOdooからプッシュすることです。

少し先に、いくつかのデータパスを逆にする必要があります。 Kibanaは私にとって優れたビジュアライザーですが、クライアントダッシュボードを介して直接レポートするために、Odooでいくつかのダッシュボードを構築する必要があります。

@lasleyここでhttps ： odoo-elasticsearch-kibana依存関係ではありません。 これは、通常のユーザーがレポート用にOdooモデルを設計できるようにするツールです。 sql_viewを実行するのと似ていますが、権限はユーザーの手にあります。

また、統計をOdooからプッシュしたいと考えています。その目的は、ユーザーがOdooからエクスポートする統計を設計できるようにすることです。

リバースパスも素晴らしいでしょう。

@ jbeficent-それは確かにかなりクールです。 NoSQL用にこのようなものを作成することも、関係がないためにはるかに簡単になるでしょう。

このようなものをサポートするには、おそらくインデックスのメソッドを＃645に追加する必要があります。これには、私が開発しなかったインデックス分析の概念が必要になります。

興味のある人にpingを送信します-誰かが調べたい場合は、 ます。 これにはまだビューフレームワークが欠けていますが、おそらく正しい方向に進んでいると思います。