Hibernate-reactive: تصدير المخطط عبر برنامج تشغيل Vert.x بدلاً من JDBC

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

اه اسف. لقد أدركت للتو أنك لم تكن تتحدث عن أسماء الممتلكات.

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

على أي حال ، أعتقد أنه سيتعين علينا الحصول على خصائص مماثلة لتلك الخاصة بـ ORM ولكن
مع إزالة الجزء jdbc من الاسم.
وحدد ما سيحدث إذا تم تعيين نوع واحد فقط من الخصائص.

يوم الجمعة 1 مايو 2020 الساعة 5:53 مساءً Andrew Guibert [email protected]
كتب:

على نفس المنوال ، لا أعتقد أننا يجب أن نبالغ في صنع الأشياء
ملائم / مألوف. على سبيل المثال ، نحن ندعم الآن تكوين RX مع
عنوان URL لبروتوكول jdbc مناسب / مألوف ولكن ليس تقنيًا
صحيح لأننا لا نستخدم JDBC.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

على أي حال ، أعتقد أنه سيتعين علينا الحصول على خصائص مماثلة لتلك الخاصة بـ ORM ولكن مع إزالة الجزء jdbc من الاسم.

أعتقد أننا يجب أن نلتزم بتنسيق عنوان URL القياسي لـ JDBC للأسباب التالية:

• إنه قياسي
• تم توثيقه جيدًا من قبل بائعي قواعد البيانات
• الجميع يعرف ذلك بالفعل
• يسهل تكوين Hibernate RX و Hibernate العادي أو JDBC العادي في نفس الوقت

DavideD ربما لم

لإعادة تحديد النية التي أملكها مع هذه المشكلة ، أقترح أنه يمكن إجراء إجراءات الإفلات / الإنشاء التلقائي للجدول دون الحاجة إلى إشراك أي برامج تشغيل JDBC أو تكوين jdbc فقط (إذا حدث RX لإعادة استخدام نفس الخصائص ، لا بأس بذلك)

اه اسف. لقد أدركت للتو أنك لم تكن تتحدث عن أسماء الممتلكات.

نعم ، فهمت. خطأي. قرأته بسرعة كبيرة في المرة الأولى.

يبدو محرجًا بعض الشيء أن تطلب من المستخدمين إضافة / تكوين برنامج تشغيل JDBC إذا كان تطبيقهم يستخدم RX فقط.

جعلتني هذه الجملة هنا أعتقد أنك كنت تتحدث عن حقيقة أننا نستخدم خصائص تكوين JDBC الموجودة بالفعل في ORM. لا يزال من الجيد أننا تحدثنا عنها ولا أخطط لتغييرها في الوقت الحالي.

لذلك كنت أجادل سابقًا في أن القيام بتصدير مخطط قاعدة البيانات عبر JDBC كان جيدًا تمامًا. (ما هو تصدير مخطط تفاعلي؟)

ومع ذلك ، في محادثة هاتفية مع emmanuelbernard و Sanne ، لفت انتباهي أن هذه بالفعل نقطة ألم محتملة لمستخدمي Quarkus.

كان يجب أن أهتم أكثر بـ aguibert عندما حاول

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

فكرة غريبة - سامحني إذا كانت سخيفة لأنني لا أعرف حقًا - ولكن أتساءل عما إذا كان بإمكاننا تغليف برنامج التشغيل التفاعلي في محول متوافق مع JDBC ، ثم إدخاله في الكود العام للمخطط؟

أعتقد أن مثل هذا العمل سيكون مبالغة إذا كان سيسهل فقط أدوات المخطط ، ولكن ربما هناك المزيد من الاستخدامات؟

تضمين التغريدة

حسنًا ، هناك تجريد هنا ، يسمى GenerationTarget . قد نكون قادرين على تنفيذ ذلك ، على الرغم من أنني لست متأكدًا بنسبة 100 ٪ بالضبط كيف يمكن للمرء أن يقوم بتوصيل واحد.

إذا تعذر ذلك ، فإن أحد الأشياء التي قد نتمكن من القيام بها هو مطالبة أداة تصدير المخطط بتصدير SCRIPT ، ثم إرسال الأوامر واحدًا تلو الآخر إلى قاعدة البيانات.

قد نكون قادرين على تنفيذ ذلك ، على الرغم من أنني لست متأكدًا بنسبة 100 ٪ بالضبط كيف يمكن للمرء أن يقوم بتوصيل واحد.

المشكلة هي أن قائمة هذه الأهداف تبدو وكأنها مقفلة ، دون أي طريقة واضحة لإضافة واحدة جديدة. لكن إصلاحًا بسيطًا للجوهر قد يكون كافيًا لحل ذلك.

نعم. على الرغم من أن هذا لا يزال يمثل أولوية قصوى ، إلا أنني سأؤجل إصدار ORM التالي بقدر الإمكان ، لذلك في حال وجد شخص ما الوقت ، يمكننا تضمين المزيد من تصحيحات اللحظة الأخيرة.

كمرجع ، تذكر أن تنفيذ الإصدار لا يستغرق منا وقتًا طويلاً: حوالي 20 دقيقة. ولكن بعد ذلك نحتاج إلى انتظار مزامنة Maven المركزية وكل ذلك قبل أن يمكن استخدامها فعليًا :(
مما يعني أننا بحاجة إلى إطلاق سراح حوالي 24 ساعة قبل أن يكون الإصدار التفاعلي ممكنًا.

سأخصص بعض الوقت لمحاولة ذلك. ربما يكون الأمر بسيطًا للغاية. سنكتشف.

ربما يكون الأمر بسيطًا للغاية. سنكتشف.

لذلك ، في الواقع ، كان الأمر واضحًا نسبيًا ، لكنه أثار مشكلة لم أفكر فيها: لم يعد بإمكان Hibernate Reactive الوصول إلى بيانات JDBC الوصفية ، والتي لها بعض العواقب ، لكنني لا أعتقد أنها فظيعة جدًا . لحسن الحظ ، تمت كتابة Hibernate عندما كانت بيانات JDBC الوصفية غير موثوقة للغاية ، ولا تعتمد عليها حقًا.

أعتقد أن هذا جيد.

كما كشفت عن خطأ في ForeignKeys حيث يستخدم Hibernate Reactive اتصال JDBC للحصول على لقطات من قاعدة البيانات! سأفتح تقرير خطأ منفصل لهذه المشكلة.

رائع شكرا!

تم دمج إصلاح Gavin في ORM ؛ يجب أن يكون إنشاء المخطط ممكنًا الآن.

أظن أن تحديث المخطط التلقائي أكثر تعقيدًا إلى حد ما - هل يمكننا الاتفاق على أن هذا أقل أهمية بالنسبة للخط الأول؟

تم دمج إصلاح Gavin في ORM ؛ يجب أن يكون إنشاء المخطط ممكنًا الآن.

شكرا.

أظن أن تحديث المخطط الآلي أكثر تعقيدًا إلى حد ما

أوه، أكثر صعوبة بكثير، منذ تنفيذ الحالي يستند كليا على JDBC الفوقية، IIRC.

هل يمكننا الاتفاق على أن هذا أقل أهمية بالنسبة للقطع الأول؟

نعم ، ليس لدي أي نية على الإطلاق للعمل على ذلك في هذه المرحلة. ولا أعتقد أنه مطلوب.

Sanne كم من الوقت قبل أن نحصل على إصدار ORM core مع هذا التغيير فيه؟

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

Sanne No انتظر بشدة ، تم تقديم هذا التعليق قبل أن أكتشف خطورة # 113.

gavinking في مرحلة ما ، هل يمكنك كتابة مشكلة على Vertx-sql-client تحدد أنواع البيانات الوصفية لقاعدة البيانات التي يحتاجها Hibernate؟ يجب أن يكون لدى عميل Vertx واجهة برمجة تطبيقات للبيانات الوصفية أفضل مما هو عليه حاليًا في يوم من الأيام.

+1 لأندرو!

لدينا مبادرة لإنشاء واجهة برمجة تطبيقات لجلب البيانات الوصفية لـ Postgres بتنسيق
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. سوف التقيمات
تساعدنا بالتأكيد في إنشاء واجهة برمجة تطبيقات عامة أفضل حول هذا الموضوع.

يوم الخميس 14 مايو 2020 الساعة 9:58 مساءً Andrew Guibert [email protected]
كتب:

gavinking https://github.com/gavinking في مرحلة ما هل يمكن أن تكتب
مشكلة في Vertx-sql-client تحدد أنواع البيانات الوصفية لقاعدة البيانات
التي يحتاجها السبات؟ يجب أن يكون لدى عميل Vertx واجهة برمجة تطبيقات أفضل للبيانات الوصفية
مما هو عليه الآن في يوم من الأيام.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 لذلك ، من أجل التجريد بعيدًا عن اختلافات النظام الأساسي.

لقد انتهى هذا!

ويتم ذلك بطريقة شفافة جدًا للمستخدم: إذا كان لديهم برنامج تشغيل JDBC أو مجموعة اتصال تم إعدادها ، فسيقوم Hibernate ORM بتصدير المخطط عبر JDBC ولكن إذا لم يكن لديهم برنامج تشغيل JDBC ، فسيتم تصدير المخطط عبر سيبدأ برنامج التشغيل Vert.x.

هذا رائع!
شكرا جزيلا

ويتم ذلك بطريقة شفافة جدًا للمستخدم: إذا كان لديهم برنامج تشغيل JDBC أو تجمع اتصال تم إعداده ، فسيقوم Hibernate ORM بتصدير المخطط عبر JDBC ولكن _iff_ ليس لديهم برنامج تشغيل JDBC ، ثم يتم تصدير المخطط عبر سيبدأ برنامج التشغيل Vert.x.

مجرد فضول ، لماذا يجب أن تحاول استخدام نهج JDBC أولاً؟ إذا كانت لدينا القدرة على تشغيله فوق الرأس ، فلماذا لا نفعله دائمًا؟

قد يكون الأمر مربكًا للمستخدمين إذا كانت هناك سلوكيات مختلفة يتم تشغيلها لمجرد أنه يتم إعداد بعض الاتصالات غير ذات الصلة. أيضًا - كيف تعرف ما إذا كان هذا الاتصال الآخر يشير حقًا إلى نفس قاعدة البيانات؟

مجرد فضول ، لماذا يجب أن تحاول استخدام نهج JDBC أولاً؟ إذا كانت لدينا القدرة على تشغيله فوق الرأس ، فلماذا لا نفعله دائمًا؟

حسنًا ، إذا كان لديك Hibernate منتظم تم إعداده باستخدام برنامج تشغيل JDBC عادي ، فلماذا لا تستخدمه؟ تصدير المخطط التفاعلي ليس شيئًا ذا مغزى. لجعل هذا العمل ناجحًا ، يتعين علينا إجراء join() سيئًا تمامًا في النهاية ، وهو ما وجده Vert.x مزعجًا للغاية.

كيف تعرف ما إذا كان هذا الاتصال الآخر يشير حقًا إلى نفس قاعدة البيانات؟

لأنه نفس عنوان URL لـ JDBC؟