Hibernate-reactive: स्कीमा निर्यात JDBC के बजाय Vert.x ड्राइवर के माध्यम से

यह थोड़ा अजीब है। साथ ही मैं एक ही कनेक्शन स्ट्रिंग को कॉन्फ़िगर करने के लिए बहुत अधिक तरीके नहीं रखना पसंद करूंगा। भविष्य में एक उपयोगकर्ता संभवतः Rx के साथ ORM का उपयोग करने में सक्षम होगा और वह केवल कुछ मामलों में Rx API का उपयोग करना चाहेगा। यह भी अच्छा है कि हम उन गुणों का उपयोग करते हैं जो पहले से ही एक ओआरएम उपयोगकर्ता से परिचित हैं।

आह क्षमा करें। मुझे अभी एहसास हुआ है कि आप संपत्ति के नाम के बारे में बात नहीं कर रहे थे।

अधिकतर, मैं सोच रहा हूं कि कोई उपयोग केस है जहां कोई उपयोग करना चाहेगा
विभिन्न विन्यास पैरामीटर।
मुझे लगता है कि ऐसा हो सकता है अगर देशी प्रतिक्रियाशील चालक के पास कुछ विशिष्ट हो
गुण।

वैसे भी, मुझे लगता है कि हमारे पास ओआरएम वाले समान गुण होंगे लेकिन
नाम से jdbc भाग हटा दिया गया है।
और तय करें कि क्या होता है यदि केवल एक प्रकार की संपत्तियां सेट की जाती हैं।

शुक्र, 1 मई, 2020 को शाम 5:53 बजे एंड्रयू गुइबर्ट नोटिफिकेशन @github.com
लिखा था:

उसी टोकन से मुझे नहीं लगता कि हमें चीजों को बनाने के साथ आगे बढ़ना चाहिए
सुविधाजनक / परिचित। उदाहरण के लिए, अभी हम RX को कॉन्फ़िगर करने का समर्थन करते हैं
एक jdbc प्रोटोकॉल URL, जो सुविधाजनक/परिचित है लेकिन तकनीकी रूप से नहीं है
सही है क्योंकि हम JDBC का उपयोग नहीं कर रहे हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

वैसे भी, मुझे लगता है कि हमारे पास ओआरएम वाले के समान गुण होंगे लेकिन नाम से jdbc भाग हटा दिया जाएगा।

मुझे लगता है कि हमें मानक JDBC URL प्रारूप के साथ रहना चाहिए क्योंकि:

• यह मानक है
• यह डेटाबेस विक्रेताओं द्वारा अच्छी तरह से प्रलेखित है
• हर कोई इसे पहले से जानता है
• यह एक ही समय में हाइबरनेट आरएक्स और सादे हाइबरनेट या सादे जेडीबीसी को कॉन्फ़िगर करना आसान बनाता है

@ डेविड डी मैंने ओपी में इस मुद्दे का ठीक से वर्णन नहीं किया हो सकता है, लेकिन स्कीमा जीन के लिए कॉन्फ़िगरेशन पैरामीटर कैसे खेलता है?

इस मुद्दे के साथ मेरे इरादे को फिर से बताने के लिए, मैं सुझाव दे रहा हूं कि किसी भी जेडीबीसी ड्राइवर या जेडीबीसी-केवल कॉन्फ़िगरेशन को शामिल किए बिना स्वचालित ड्रॉप/टेबल टेबल प्रक्रियाएं की जा सकती हैं (यदि आरएक्स समान गुणों का पुन: उपयोग करने के लिए होता है , हालांकि यह ठीक है)

आह क्षमा करें। मुझे अभी एहसास हुआ है कि आप संपत्ति के नाम के बारे में बात नहीं कर रहे थे।

हाँ, मिल गया। मेरा बुरा। मैंने इसे पहली बार बहुत जल्दी पढ़ा।

यह थोड़ा अजीब लगता है कि उपयोगकर्ताओं को JDBC ड्राइवर जोड़ने/कॉन्फ़िगर करने की आवश्यकता होती है यदि उनका ऐप केवल RX का उपयोग कर रहा है।

यहां इस वाक्य ने मुझे यह सोचने पर मजबूर कर दिया कि आप इस तथ्य के बारे में बात कर रहे थे कि हम जेडीबीसी कॉन्फ़िगरेशन के लिए गुणों का उपयोग करते हैं जो पहले से ही ओआरएम में मौजूद हैं। यह अभी भी अच्छा है कि हमने इसके बारे में बात की और मैं अभी उन्हें बदलने की योजना नहीं बना रहा हूं।

तो पहले मैं तर्क दे रहा था कि जेडीबीसी पर स्कीमा निर्यात करना बिल्कुल ठीक था। (एक प्रतिक्रियाशील स्कीमा निर्यात क्या है?)

हालांकि, @emmanuelbernard और @Sanne साथ फोन पर बातचीत में, यह मेरी पता चला है कि यह वास्तव में वास्तव में Quarkus उपयोगकर्ताओं के लिए एक संभावित दर्द बिंदु है।

मुझे @aguibert पर अधिक ध्यान देना चाहिए था जब उसने मुझे इस बारे में चेतावनी देने की कोशिश की।

तो, वैसे भी, यह वास्तव में एक ऐसा मुद्दा है जिसे हमें प्राथमिकता देनी चाहिए, हालांकि मुझे संदेह है कि इसे प्रारंभिक रिलीज के लिए समय पर नहीं किया जा सकता है।

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

मुझे लगता है कि इस तरह का काम अधिक हो जाएगा यदि यह केवल स्कीमाजेन टूल्स की सुविधा प्रदान करेगा, लेकिन शायद और भी उपयोग हैं?

@ साने

वैसे यहाँ एक अमूर्तता है, जिसे GenerationTarget कहा जाता है। हम इसे लागू करने में सक्षम हो सकते हैं, हालांकि मैं 100% निश्चित नहीं हूं कि कोई एक को प्लग इन करने के बारे में कैसे जाता है।

ऐसा न होने पर, एक चीज जो हम करने में सक्षम हो सकते हैं, वह है स्कीमा एक्सपोर्ट टूल को SCRIPT निर्यात करने के लिए कहना, और फिर डीबी को एक-एक करके कमांड भेजें।

हम इसे लागू करने में सक्षम हो सकते हैं, हालांकि मैं 100% निश्चित नहीं हूं कि कोई एक को प्लग इन करने के बारे में कैसे जाता है।

समस्या यह है कि इन लक्ष्यों की सूची में कोई नया जोड़ने का कोई स्पष्ट तरीका नहीं है। लेकिन इसे हल करने के लिए कोर के लिए एक छोटा सा फिक्स पर्याप्त हो सकता है।

ठीक। हालांकि यह अभी भी सर्वोच्च प्राथमिकता नहीं है, मैं अगले ओआरएम को जितना संभव हो उतना जारी करना टाल दूंगा, इसलिए यदि किसी को समय मिलता है तो हम कुछ और अंतिम मिनट पैच शामिल कर सकते हैं।

संदर्भ के लिए, याद रखें कि रिलीज़ को निष्पादित करने में वास्तव में हमें ज़्यादा समय नहीं लगता: लगभग २० मिनट। लेकिन फिर हमें मेवेन केंद्रीय सिंक्रनाइज़ेशन की प्रतीक्षा करने की आवश्यकता है और इससे पहले कि इसका वास्तव में उपयोग किया जा सके :(
इसका मतलब है कि रिएक्टिव रिलीज संभव होने से पहले हमें लगभग 24 घंटे रिलीज करने की जरूरत है।

मैं इसे आजमाने के लिए कुछ समय निकालूंगा। शायद यह सुपर-सरल है। हम पता कर लेंगे।

शायद यह सुपर-सरल है। हम पता कर लेंगे।

तो, वास्तव में, यह अपेक्षाकृत सरल था, लेकिन इसने एक ऐसा मुद्दा उठाया जिस पर मैंने विचार नहीं किया था: हाइबरनेट रिएक्टिव के पास अब JDBC मेटाडेटा तक पहुंच नहीं है, जिसके कुछ परिणाम हैं, लेकिन मुझे नहीं लगता कि वे बहुत भयानक हैं। सौभाग्य से हाइबरनेट तब लिखा गया था जब जेडीबीसी मेटाडेटा बहुत अविश्वसनीय था, और वास्तव में इस पर निर्भर नहीं है।

मुझे लगता है कि ठीक है।

साथ ही इसने ForeignKeys में एक बग का खुलासा किया जहां हाइबरनेट रिएक्टिव वास्तव में डेटाबेस से स्नैपशॉट प्राप्त करने के लिए JDBC कनेक्शन का उपयोग करेगा! मैं उस समस्या के लिए एक अलग बग रिपोर्ट खोलूंगा।

बहुत अच्छे धन्यवाद!

गेविन का फिक्स ओआरएम में विलय कर दिया गया था; स्कीमा निर्माण अब करने योग्य होना चाहिए।

मुझे संदेह है कि स्वचालित स्कीमा अपडेट थोड़ा अधिक जटिल है - क्या हम सहमत हो सकते हैं कि पहले कट के लिए कम महत्वपूर्ण है?

गेविन का फिक्स ओआरएम में विलय कर दिया गया था; स्कीमा निर्माण अब करने योग्य होना चाहिए।

धन्यवाद।

मुझे संदेह है कि स्वचालित स्कीमा अपडेट हालांकि थोड़ा अधिक जटिल है

ओह, और अधिक कठिन, क्योंकि वर्तमान कार्यान्वयन पूरी तरह से JDBC मेटाडेटा, IIRC पर आधारित है।

क्या हम सहमत हो सकते हैं कि पहले कट के लिए कम महत्वपूर्ण है?

हाँ, इस स्तर पर उस पर काम करने का मेरा कोई इरादा नहीं है। न ही मुझे लगता है कि इसकी जरूरत है।

@Sanne उस बदलाव के साथ ORM कोर को रिलीज़ करने से पहले हमें कितना समय लगता है?

@gavinking हम सोमवार को रिलीज की योजना बना सकते हैं। मुझे आश्चर्य है कि - यदि संभवतः अधिक परिवर्तनों की आवश्यकता है तो शायद इसे स्थगित करना सबसे अच्छा है?
हम कुछ अन्य सुधारों पर भी काम कर रहे हैं जिनकी क्वार्कस को आवश्यकता है - इसलिए जब भी हम किसी एक को जब चाहें रिलीज़ कर सकते हैं, बाद में अधिक सुधार।

@Sanne नो होल्ड टाइट, वह टिप्पणी # 113 की गंभीरता का पता

@ किसी बिंदु पर

एंड्रयू के लिए +1!

हमारे पास पोस्टग्रेज के लिए एपीआई लाने वाला मेटाडेटा बनाने की पहल है
https://github.com/eclipse-vertx/vertx-sql-client/pull/513। प्रतिक्रिया होगी
निश्चित रूप से इसके आसपास एक बेहतर जेनेरिक एपीआई बनाने में हमारी मदद करें।

गुरु, 14 मई, 2020 को रात 9:58 बजे एंड्रयू गुइबर्ट नोटिफिकेशन @github.com
लिखा था:

@gavinking https://github.com/gavinking कभी आप लिख सकते हैं
वर्टेक्स-एसक्यूएल-क्लाइंट पर एक मुद्दा यह बताता है कि किस प्रकार का डीबी मेटाडेटा है
हाइबरनेट द्वारा आवश्यक? Vertx क्लाइंट के पास बेहतर मेटाडेटा API होना चाहिए
की तुलना में यह वर्तमान में किसी दिन करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

स्कीमा प्रबंधन टूल को information_schema.tables में जानकारी तक पहुंच की आवश्यकता है और मुझे लगता है कि information_schema.key_column_usage ।

स्कीमा प्रबंधन टूल को information_schema.tables में जानकारी तक पहुंच की आवश्यकता है और मुझे लगता है कि information_schema.key_column_usage ।

ध्यान दें कि information_schema को क्वेरी करके सीधे उस जानकारी को प्राप्त करने के लिए एक विकल्प है। ऐतिहासिक रूप से यह उसके लिए सिर्फ JDBC मेटाडेटा एपीआई है, ताकि प्लेटफॉर्म के अंतर से दूर हो सके।

यह हो गया!

और यह इस तरह से किया गया है जो उपयोगकर्ता के लिए बहुत पारदर्शी है: यदि उनके पास जेडीबीसी ड्राइवर या कनेक्शन पूल स्थापित है, तो हाइबरनेट ओआरएम जेडीबीसी पर स्कीमा निर्यात करेगा लेकिन अगर उनके पास जेडीबीसी ड्राइवर नहीं है, तो स्कीमा निर्यात खत्म हो गया है Vert.x ड्राइवर किक करेगा।

वह तो कमाल है!
बहुत - बहुत धन्यवाद

और यह इस तरह से किया गया है जो उपयोगकर्ता के लिए बहुत पारदर्शी है: यदि उनके पास जेडीबीसी ड्राइवर या कनेक्शन पूल स्थापित है, तो हाइबरनेट ओआरएम जेडीबीसी पर स्कीमा निर्यात करेगा लेकिन _iff_ उनके पास जेडीबीसी ड्राइवर नहीं है, फिर स्कीमा निर्यात खत्म हो गया है Vert.x ड्राइवर किक करेगा।

बस जिज्ञासु, इसे पहले JDBC दृष्टिकोण का उपयोग करने का प्रयास क्यों करना चाहिए? यदि हमारे पास इसे शीर्ष पर चलाने की क्षमता है, तो इसे हमेशा क्यों न करें?

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

बस जिज्ञासु, इसे पहले JDBC दृष्टिकोण का उपयोग करने का प्रयास क्यों करना चाहिए? यदि हमारे पास इसे शीर्ष पर चलाने की क्षमता है, तो इसे हमेशा क्यों न करें?

ठीक है अगर आपके पास नियमित जेडीबीसी ड्राइवर के साथ नियमित हाइबरनेट है तो इसका उपयोग क्यों न करें? प्रतिक्रियाशील स्कीमा निर्यात एक सार्थक बात नहीं है। इसे भी काम करने के लिए हमें अंत में पूरी तरह से खराब join() करना होगा, जो Vert.x को काफी परेशान करता है।

आप कैसे जानते हैं कि वह अन्य कनेक्शन वास्तव में उसी डीबी को इंगित करता है?

क्या यह वही JDBC URL है?