Server-tools: [RFC] base_elasticsearch

Halo @lasley di Akretion, kami mungkin memulai apa yang Anda butuhkan:
https://github.com/akretion/connector-nosql
juga lihat cabang solr https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
tolong, mari kita kerjakan ini bersama-sama. Kami memiliki pengalaman hebat dalam mengintegrasikan Odoo dengan Solr dan penyimpanan data NoSQL Algolia.

Bagus, terima kasih @rvalyi - sepertinya Anda sudah memulai apa yang saya butuhkan.

Sayangnya salah satu persyaratan proyek saya adalah bahwa itu harus LGPL - saya seharusnya menyebutkan itu di RFC saya di belakang (diedit untuk memasukkannya). Persyaratan LGPL mengesampingkan penggunaan connector , dan juga mengesampingkan penyertaan logika ini ke dalam base_external_dbsource . Persyaratan ini disebabkan oleh rencana penggunaan modul ini sebagai bagian dari infrastruktur penagihan SaaS inti saya.

Saya melihat banyak logika ekspor di sini, tetapi tidak ada apa pun untuk membaca data. Apakah saya benar dalam penilaian itu?

Bagaimana Anda menghindari kebutuhan untuk menyimpan data di Odoo?

@lasley Saya penulis logika di base_external_dbsource . Saya melihat sejarah dan satu-satunya kontribusi asli lainnya adalah menambahkan koneksi Firebird DB. Jika penting, kami dapat mempertimbangkan untuk melisensikan kembali modul tersebut ke LGPL.
Faktanya, karena mereka hanya alat teknis, saya tidak akan melihat masalah untuk repo alat server menjadi LGPL sebanyak mungkin.

@dreispt - Saya ingin menambahkan logika ke modul yang ada jika Anda mahir dengan lisensi. Saya akan menggunakan basis ini untuk penyerapan metrik dan penagihan selanjutnya dari penawaran SaaS saya, jadi tidak membiarkan AGPL meresap ke dalam itu adalah pemblokir mutlak.

Pada awalnya, koneksi Elastis sederhana juga benar-benar kita butuhkan, jadi base_external_dbsource cocok. Saya juga kemungkinan akan melakukan refactor sedikit untuk menyingkirkan rantai if di dalam conn_open dan execute yang akan menjadi lebih besar secara eksponensial karena lebih banyak sumber mulai ditambahkan.

NoSQL sedikit berbeda dalam hal kueri, tetapi saya masih bisa masuk ke antarmuka execute dengan sedikit adaptasi kreatif.

@lasley oke. Untuk menghormati semua kontribusi lain, seperti porting dari versi, saya akan membuka Masalah untuk mengusulkan dan mendiskusikan perubahan lisensi.
Dan kita harus membuat modul "pluggable", di mana dukungan untuk database tambahan, seperti Firebird, dapat dipasang oleh modul tambahan.

Terima kasih @dreispt - sangat dihargai!

Mengenai pluggable - Apa yang Anda pikirkan? Refactoring yang saya rencanakan benar-benar hanya untuk memecahkan dua rantai raksasa jika, tapi saya terbuka untuk perbaikan lain saat itu di piring dev saya.

@lasley maksud saya membuatnya mudah untuk diperluas oleh modul lain. Dukungan db tambahan dapat ditambahkan dengan modul ekstensi tambahan.

@dreispt Ahhh iya

Adakah pemikiran bagi saya untuk menghapus semua sumber database independen ke dalam modul mereka sendiri? Saya merasa ini coba/kecuali hal di atas agak berat, apakah Anda setuju? Ini adalah solusi saat ini , tetapi saya pikir itu masih bisa ditingkatkan.

Apakah ini sesuatu yang harus kita tunggu hingga v11 aktif karena rilis stabil? Atau apakah merilis bersama dengan modul pengganti dapat diterima?

Saya juga berpikir mungkin akan lebih baik untuk menambahkan antarmuka tipe CRUD dasar juga sehingga mungkin kita bisa berpikir untuk menjauh dari SQL langsung.

IMO akan lebih bersih untuk modul ekstensi untuk hanya melakukan pemikiran biasa: mewarisi model base.external.dbsource untuk memodifikasi fitur dan model.

Masuk akal untuk mengekstrak penyedia db untuk 10.0, karena ini adalah versi baru, tetapi mungkin tidak masuk akal untuk 9.0 - dan pembaruan akan merusak instalasi yang ada.

10.0 sudah dirilis & tampaknya menjadi migrasi 1:1. Saya pikir kita harus menunggu sampai 11 untuk mematuhi kebijakan rilis stabil, bukan?

Tegasnya ya.
Itu berarti kita tidak boleh menghapus fitur dari modul saat ini.

Bagaimana jika kami membuat modul baru dipasang secara otomatis di versi yang lebih rendah? Akan memungkinkan isolasi saat saya di sini, dengan sakelar mati yang mudah untuk nanti.

API yang dihadapi eksternal akan sama, jadi saya rasa kami tidak akan menyebabkan masalah?

@lasley Ya, itu ide yang bagus.

Hai, yang di sana,

@lasley Mungkin Anda ingin melihat https://github.com/camptocamp/odoo-elasticsearch-kibana

Salam,

Joël

Menindaklanjuti apa yang ditunjukkan @jgrandguillaume di atas, kami hanya berdiskusi dengannya bahwa apa yang akan menjadi hebat adalah memiliki alat seperti https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor untuk menentukan model pelaporan di Odoo, lalu untuk dapat mengekspor data untuk model ini ke ElasticSearch, sehingga dapat digabungkan dengan sumber data lain dan kemudian melaporkannya menggunakan Kibana.

Sekarang, saya tidak yakin apakah ini pendekatan yang diikuti @lasley pada RFC ini?¿?

Menarik dalam kedua hal, terima kasih @jgrandguillaume & @jbeficent.

Apakah bi_view_editor itu @jbeficent menautkan bentuk yang ditingkatkan dari sql_view yang ditautkan sebagai ketergantungan modul untuk odoo-elasticsearch-kibana ?

Saya memiliki semacam niat multi-tujuan dengan RFC ini. Maksud utamanya adalah untuk mendorong statistik keluar dari Odoo, mirip dengan apa yang dilakukan di kedua pustaka yang ditautkan.

Sedikit lebih jauh, saya perlu membalik beberapa jalur data. Kibana adalah visualisator yang hebat bagi saya, tetapi saya perlu membuat beberapa dasbor di Odoo untuk pelaporan langsung melalui dasbor klien.

@lasley Lihat bi_view_editor di sini: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. Saat ini bukan ketergantungan untuk odoo-elasticsearch-kibana . Ini adalah alat yang memungkinkan pengguna biasa merancang model Odoo untuk tujuan pelaporan. Mirip dengan melakukan sql_view, tetapi kekuatan ada di tangan pengguna.

Kami juga ingin mengeluarkan statistik dari Odoo, dan tujuannya adalah agar pengguna memiliki kemampuan untuk merancang statistik apa yang ingin dia ekspor dari Odoo.

Jalur mundur juga bagus.

@jbeficent - Yah itu memang cukup keren. Membuat sesuatu seperti ini untuk NoSQL kemungkinan akan jauh lebih mudah juga karena kurangnya hubungan.

Saya mungkin perlu menambahkan beberapa metode untuk indeks ke #645 saya untuk mendukung sesuatu seperti ini, yang memerlukan konsep analisis indeks yang tidak saya kembangkan.

Ping ke siapa pun yang tertarik - Saya meletakkan desain data awal di https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 jika ada yang ingin melihatnya. Ini masih kekurangan kerangka pandang, tapi saya pikir mungkin menempatkan kita di jalur yang benar.