Server-tools: [आरएफसी] बेस_इलास्टिक्स खोज

नमस्ते @lasley Akretion पर हमने शायद वही शुरू किया जो आपको चाहिए:
https://github.com/akretion/connector-nosql
सौर शाखा भी देखें https://github.com/akretion/connector-nosql/tree/9.0-solr
cc @sebastienbeau
कृपया इस पर एक साथ काम करें। हमारे पास पहले से ही सोलर और अल्गोलिया नोएसक्यूएल डेटा स्टोर के साथ ओडू को एकीकृत करने का एक अच्छा अनुभव है।

अच्छा, धन्यवाद @rvalyi - यह वास्तव में ऐसा लगता है कि आपने मुझे जो चाहिए वह शुरू कर दिया है।

दुर्भाग्य से मेरी परियोजना की आवश्यकताओं में से एक यह है कि इसे एलजीपीएल होना चाहिए - मुझे यह उल्लेख करना चाहिए था कि मेरे आरएफसी में पिछली बार (इसे शामिल करने के लिए संपादित)। LGPL आवश्यकता connector के उपयोग को नियंत्रित करती है, और इस तर्क को base_external_dbsource में शामिल करने से भी इंकार करती है। यह आवश्यकता मेरे मूल SaaS बिलिंग अवसंरचना के भाग के रूप में इस मॉड्यूल के मेरे नियोजित उपयोग के कारण है।

मुझे यहां बहुत सारे निर्यात तर्क दिखाई देते हैं, लेकिन डेटा पढ़ने के लिए कुछ भी नहीं है। क्या मैं उस मूल्यांकन में सही हूँ?

आपने ओडू में डेटा स्टोर करने की आवश्यकता को कैसे दरकिनार किया?

@lasley मैं base_external_dbsource में तर्क के लिए लेखक हूं। मैंने इतिहास को देखा और केवल अन्य मूल योगदान फायरबर्ड डीबी कनेक्शन जोड़ रहा है। यदि यह महत्वपूर्ण है, तो हम उस मॉड्यूल को LGPL को पुनः लाइसेंस देने पर विचार कर सकते हैं।
असल में, चूंकि वे केवल तकनीकी उपकरण हैं, इसलिए मुझे सर्वर-टूल्स रेपो जितना संभव हो उतना एलजीपीएल होने में कोई समस्या नहीं दिखाई देगी।

@dreispt - यदि आप

शुरुआत में एक साधारण लोचदार कनेक्शन वास्तव में हमें भी चाहिए, इसलिए base_external_dbsource फिट बैठता है। conn_open और execute अंदर if श्रृंखलाओं से छुटकारा पाने के लिए मैं इसे थोड़ा सा रिफैक्टर भी कर सकता हूं जो अधिक स्रोतों को जोड़ने के लिए तेजी से बड़ा हो जाएगा।

NoSQL क्वेरी के मामले में थोड़ा अलग है, लेकिन मैं अभी भी execute इंटरफ़ेस में थोड़ा रचनात्मक अनुकूलन के साथ फिट हो सकता हूं।

@lasley ठीक है। अन्य सभी योगदानों का सम्मान करने के लिए, जैसे कि संस्करणों से पोर्ट करना, मैं लाइसेंस परिवर्तन का प्रस्ताव और चर्चा करने के लिए एक मुद्दा खोलूंगा।
और हमें मॉड्यूल को "प्लग करने योग्य" बनाना चाहिए, जहां फ़ायरबर्ड जैसे अतिरिक्त डेटाबेस का समर्थन एक अतिरिक्त मॉड्यूल द्वारा प्लग इन किया जा सकता है।

धन्यवाद @dreispt - बहुत सराहना की!

pluggable - आपके मन में क्या था? मेरी नियोजित रिफैक्टरिंग वास्तव में केवल दो विशाल जंजीरों को तोड़ने के लिए थी, लेकिन मैं अन्य सुधारों के लिए खुला हूं, जबकि यह मेरी देव प्लेट पर है।

@lasley मेरा मतलब है कि किसी अन्य मॉड्यूल द्वारा एक्स्टेंसिबल होना आसान बनाना। अतिरिक्त डीबी समर्थन एक अतिरिक्त एक्सटेंशन मॉड्यूल द्वारा जोड़ा जा सकता है।

@dreispt आह हाँ

मेरे लिए कोई भी विचार सभी स्वतंत्र डेटाबेस स्रोतों को अपने मॉड्यूल में अलग कर रहा है? मुझे ऐसा लगता है कि यह कोशिश/सिवाय शीर्ष पर कुछ बोझिल है, क्या आप सहमत हैं? यह वर्तमान समाधान है , लेकिन मुझे लगता है कि इसमें अभी भी सुधार किया जा सकता है।

क्या यह कुछ ऐसा है जिस पर हमें स्थिर रिलीज के कारण v11 का इंतजार करना होगा? या एक प्रतिस्थापन मॉड्यूल के साथ रिलीज करना स्वीकार्य है?

मुझे यह भी लगता है कि एक बुनियादी सीआरयूडी प्रकार इंटरफ़ेस भी जोड़ना अच्छा होगा ताकि शायद हम सीधे एसक्यूएल से दूर जाने के बारे में सोच सकें।

आईएमओ विस्तार मॉड्यूल के लिए सामान्य विचार करने के लिए क्लीनर होगा: सुविधाओं और मॉडलों को संशोधित करने के लिए base.external.dbsource मॉडल का उत्तराधिकारी।

डीबी प्रदाताओं को 10.0 के लिए निकालना उचित है, क्योंकि यह एक नया संस्करण है, लेकिन शायद यह 9.0 के लिए उचित नहीं होगा - और अपडेट मौजूदा इंस्टॉलेशन को तोड़ देगा।

हालांकि 10.0 पहले ही जारी हो चुका है और 1:1 माइग्रेशन लगता है। मुझे लगता है कि स्थिर रिलीज नीति का पालन करने के लिए हमें 11 तक इंतजार करना होगा, है ना?

कड़ाई से हाँ बोल रहा हूँ।
इसका मतलब है कि हमें मौजूदा मॉड्यूल से सुविधाओं को नहीं हटाना चाहिए।

क्या होगा यदि हमने नए मॉड्यूल को निचले संस्करणों में स्वतः स्थापित किया है? जब मैं यहां हूं, तो अलगाव की अनुमति दूंगा, बाद में एक आसान बंद स्विच के साथ।

बाहरी फेसिंग एपीआई समान होगा, इसलिए मुझे नहीं लगता कि हम कोई समस्या पैदा करेंगे?

@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 लिए मॉड्यूल निर्भरता के रूप में जुड़ा हुआ है?

इस आरएफसी के साथ मेरा एक बहुउद्देश्यीय इरादा है। मुख्य उद्देश्य आँकड़ों को ओडू से बाहर धकेलना है, जैसा कि दोनों लिंक्ड पुस्तकालयों में किया जा रहा है।

सड़क से थोड़ा आगे, मुझे कुछ डेटा पथों को उलटने की आवश्यकता होगी। किबाना मेरे लिए एक महान विज़ुअलाइज़र है, लेकिन क्लाइंट डैशबोर्ड के माध्यम से सीधे रिपोर्टिंग के लिए मुझे ओडू में कुछ डैशबोर्ड बनाने की आवश्यकता होगी।

@lasley यहां https://github.com/OCA/reporting-engine/tree/8.0/bi_view_editor। यह वर्तमान में odoo-elasticsearch-kibana लिए निर्भरता नहीं है। यह एक उपकरण है जो एक सामान्य उपयोगकर्ता को रिपोर्टिंग उद्देश्यों के लिए ओडू मॉडल डिजाइन करने की अनुमति देता है। एक sql_view करने के समान, लेकिन शक्ति उपयोगकर्ता के हाथ में है।

हम आँकड़ों को Odoo से बाहर भी धकेलना चाहते हैं, और इसका उद्देश्य यह होगा कि उपयोगकर्ता के पास यह डिज़ाइन करने की क्षमता हो कि वह Odoo से कौन से आँकड़े निर्यात करना चाहता है।

उल्टा रास्ता भी बढ़िया रहेगा।

@jbeficent - वैसे यह वास्तव में बहुत अच्छा है। संबंधों की कमी के कारण नोएसक्यूएल के लिए ऐसा कुछ बनाना बहुत आसान होगा।

मुझे शायद इस तरह से कुछ का समर्थन करने के लिए इंडेक्स के लिए मेरे # 645 में कुछ तरीकों को जोड़ने की ज़रूरत है, जिसके लिए इंडेक्स विश्लेषण की अवधारणा की आवश्यकता होगी जिसे मैंने विकसित नहीं किया था।

रुचि रखने वाले किसी भी व्यक्ति को पिंग करें - यदि कोई देखना चाहता है तो मैं https://github.com/OCA/server-tools/pull/660#issuecomment -273583948 में प्रारंभिक डेटा डिज़ाइन डालता हूं। इसमें अभी भी एक दृश्य ढांचे की कमी होगी, लेकिन मुझे लगता है कि शायद हमें सही रास्ते पर रखता है।