Server-tools: [RFC] base_elasticsearch

مرحبًا @ Lasley في Akretion ، ربما بدأنا ما تحتاجه:
https://github.com/akretion/connector-nosql
راجع أيضًا فرع solr https://github.com/akretion/connector-nosql/tree/9.0-solr
ccsebastienbeau
من فضلك دعنا نعمل على هذا معا. لدينا تجربة رائعة في دمج Odoo مع مخازن بيانات Solr و Algolia NoSQL بالفعل.

رائع ، شكرًا rvalyi - يبدو أنك بدأت ما أحتاجه بالفعل.

لسوء الحظ ، فإن أحد متطلبات مشروعي هو أنه يجب أن يكون LGPL - كان يجب أن أذكر ذلك في RFC بعد فوات الأوان (تم تعديله لتضمينه). تستبعد متطلبات LGPL استخدام connector ، وتستبعد أيضًا تضمين هذا المنطق في base_external_dbsource . يرجع هذا المطلب إلى استخدامي المخطط لهذه الوحدة كجزء من البنية التحتية الأساسية للفوترة SaaS.

أرى الكثير من منطق التصدير هنا ، لكن لا شيء لقراءة البيانات. هل أنا محق في ذلك التقييم؟

كيف تحايلت على الحاجة إلى تخزين البيانات في Odoo؟

lasley أنا مؤلف المنطق في base_external_dbsource . لقد ألقيت نظرة على التاريخ والمساهمة الأصلية الوحيدة الأخرى هي إضافة اتصالات Firebird DB. إذا كان الأمر مهمًا ، فيمكننا التفكير في إعادة ترخيص تلك الوحدة إلى LGPL.
في الواقع ، نظرًا لأنها مجرد أدوات تقنية ، فلن أرى مشكلة في إعادة شراء أدوات الخادم لتكون LGPL قدر الإمكان.

dreispt - أرغب في إضافة المنطق إلى الوحدة النمطية الحالية إذا كنت جيدًا مع البقايا. سأستخدم هذه القاعدة لاستيعاب المقاييس والفوترة اللاحقة لعروض SaaS الخاصة بي ، لذا فإن عدم السماح لـ AGPL بالتغلغل في هذا هو مانع مطلق.

في البداية ، يكون الاتصال المرن البسيط هو كل ما نحتاجه أيضًا ، لذا يناسبك base_external_dbsource . من المحتمل أيضًا أن أعيد بنائه قليلاً للتخلص من سلاسل if داخل conn_open و execute التي ستصبح أكبر بشكل كبير مع بدء إضافة المزيد من المصادر.

يختلف NoSQL قليلاً من حيث الاستعلام ، ولكن لا يزال بإمكاني التوافق مع واجهة execute مع القليل من التكيف الإبداعي.

@ لاسلي موافق. لاحترام جميع المساهمات الأخرى ، مثل النقل من الإصدارات ، سأفتح إصدارًا لاقتراح تغيير الترخيص ومناقشته.
ويجب أن نجعل الوحدة "قابلة للتوصيل" ، حيث يمكن توصيل الدعم لقواعد البيانات الإضافية ، مثل Firebird ، بوحدة إضافية.

شكرا @ dreispt - أقدر ذلك كثيرا!

بخصوص pluggable - ما الذي يدور في ذهنك؟ كانت عملية إعادة البناء التي خططت لها هي فقط كسر السلاسل العملاقة ، لكنني منفتح على التحسينات الأخرى أثناء وجودها في لوحة التطوير الخاصة بي.

lasley أعني

Dreispt Ahhh نعم مسكتك. بالتااكيد!

هل لدي أي أفكار لتجريد جميع مصادر قاعدة البيانات المستقلة في الوحدات النمطية الخاصة بهم؟ أشعر أن هذه المحاولة / باستثناء أن الشيء الموجود في الأعلى صعب بعض الشيء ، هل توافق؟ هذا هو الحل الحالي ، لكنني أعتقد أنه لا يزال من الممكن تحسينه.

هل هذا شيء يجب أن ننتظره حتى الإصدار 11 لأنه إصدار مستقر؟ أو هل يُقبل التحرير جنبًا إلى جنب مع وحدة (وحدات) بديلة؟

أعتقد أيضًا أنه قد يكون من الجيد إضافة واجهة أساسية من نوع CRUD أيضًا حتى نتمكن من التفكير في الابتعاد عن SQL المباشر.

سيكون من الأنظف لوحدة الامتداد أن تفعل التفكير المعتاد: ترث نموذج base.external.dbsource لتعديل الميزات والنماذج.

من المعقول استخراج موفري db مقابل 10.0 ، نظرًا لأنه إصدار جديد ، ولكن من المحتمل ألا يكون معقولاً بالنسبة لـ 9.0 - وقد يؤدي التحديث إلى كسر التثبيتات الحالية.

10.0 تم إصداره بالفعل على الرغم من أنه يبدو أنه ترحيل 1: 1. أعتقد أنه سيتعين علينا الانتظار حتى الساعة 11 للالتزام بسياسة الإفراج المستقرة ، أليس كذلك؟

نعم بالمعنى الدقيق للكلمة.
هذا يعني أنه لا ينبغي لنا إزالة الميزات من الوحدة الحالية.

ماذا لو أجرينا تثبيتًا تلقائيًا للوحدات النمطية الجديدة في الإصدارات السفلية؟ سيسمح بالعزلة أثناء وجودي هنا ، مع مفتاح إيقاف سهل لوقت لاحق.

ستكون واجهة API الخارجية هي نفسها ، لذلك لا أعتقد أننا قد نتسبب في أي مشاكل؟

@ Lasley نعم ، هذه فكرة جيدة.

أهلا،

lasley قد ترغب في إلقاء نظرة على https://github.com/camptocamp/odoo-elasticsearch-kibana

يعتبر،

جويل

متابعة لما يظهرهjgrandguillaume أعلاه ، نناقش معه فقط ما سيكون رائعًا أن يكون لديك أداة مثل https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor لتحديد نموذج الإبلاغ في Odoo ، ثم لتتمكن من تصدير البيانات الخاصة بهذا النموذج إلى ElasticSearch ، بحيث يمكن دمجها مع مصادر البيانات الأخرى ثم إعداد تقرير عنها باستخدام Kibana.

الآن ، لست متأكدًا تمامًا مما إذا كان هذا هو النهج الذي يتبعه @ Lasley في RFC هذا؟ ¿؟

مثيرة للاهتمام في كلا الأمرين ، شكرًا jgrandguillaume & jbeficent.

هل bi_view_editor jbeficent بربط النموذج الذي تمت ترقيته لـ sql_view المرتبط باعتباره تبعية وحدة لـ odoo-elasticsearch-kibana ؟

لدي نوع من النية متعددة الأغراض مع RFC هذا. الهدف الرئيسي هو إخراج الإحصائيات من Odoo ، على غرار ما يتم القيام به في كلتا المكتبتين المرتبطتين.

بعيدًا قليلاً عن الطريق ، سأحتاج إلى عكس بعض مسارات البيانات. Kibana هو متخيل رائع بالنسبة لي ، لكنني سأحتاج إلى إنشاء بعض لوحات المعلومات في Odoo لإعداد التقارير المباشرة عبر لوحات معلومات العميل.

lasley انظر bi_view_editor هنا: https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor. إنها ليست تبعية حاليًا لـ odoo-elasticsearch-kibana . إنها أداة تسمح للمستخدم العادي بتصميم نماذج Odoo لأغراض إعداد التقارير. على غرار إجراء sql_view ، لكن القوة في يد المستخدم.

نريد أيضًا إخراج الإحصائيات من Odoo ، والهدف هو أن يكون لدى المستخدم القدرة على تصميم الإحصاءات التي يرغب في تصديرها من Odoo.

سيكون المسار العكسي رائعًا أيضًا.

jbeficent - حسنًا ، هذا رائع حقًا. من المحتمل أن يكون إنشاء شيء كهذا لـ NoSQL أسهل بكثير بسبب نقص العلاقات.

ربما أحتاج إلى إضافة بعض الأساليب الخاصة بالمؤشرات إلى # 645 الخاص بي لدعم شيء كهذا ، والذي قد يحتاج إلى مفهوم تحليل الفهرس الذي لم أطوره.

Ping لأي شخص مهتم - أضع تصميمًا أوليًا للبيانات في https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 إذا كان أي شخص يريد إلقاء نظرة. لا يزال هذا يفتقر إلى إطار العرض ، لكن أعتقد أنه ربما يضعنا على المسار الصحيح.