Hibernate-reactive: أعد النظر في اسم "Rx"

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

نعم ، كان دائمًا اسمًا رمزيًا.

حسنًا ، من الأفضل أن نغيره سريعًا ، لأنه جيد على طول الطريق نحو ترسيخ اسم حقيقي!

لقد خصصت ذلك لي. سأفعل ذلك في نهاية الأسبوع ، ما لم يكن لدى شخص ما اعتراضات.

سأفعل ذلك في نهاية الأسبوع

ولكن ما الذي ستغيره إليه؟

hibernate-reactive سيئًا للغاية

>

+1 للسبات التفاعلي

يوم الأربعاء 1 أبريل 2020 الساعة 7:45 صباحًا كتب DavideD [email protected] :

hibernate-reactive سيئًا للغاية

>

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

هذا جيد لكني لا أريد كتابة ReactiveSession ألف مرة ....

أنا أحب HibernateRX : أن تكون "رد الفعل" هو مفهوم ، إنه ليس علامة تجارية لشركة RxJava.

هذا جيد لكني لا أريد أن أكتب جلسة رد الفعل ألف مرة.

نوع؟ لوحة المفاتيح ليس بها زر مسافة؟ :)

لكي نكون منصفين ، لا أحب استخدام البادئة في اسم الفصل. هل سيكون كافيا أن يكون في العبوة؟ أم أنه محير للغاية عند العمل مع ORM؟
ربما يمكننا استخدام R كبادئة؟

فيما يلي ملخص للخيارات التي يمكنني التفكير فيها (لا تتردد في اقتراح شيء مختلف):

1. org.hibernate.rx.RxSession (الحالية)
2. org.hibernate.rx.Session
3. org.hibernate.reactive.ReactiveSession
4. org.hibernate.reactive.Session
5. org.hibernate.reactive.RSession
6. org.hibernate.rx.RSession

أي اقتراحات أخرى؟

ليس لدي تفضيل قوي. أعتقد أن رد الفعل يجعل الاسم أكثر قابلية للقراءة وهو ليس طويلاً. لاحظ أنه ليس من الضروري أن تكون بادئة لأنه بالنسبة لبعض التنفيذ أو الفصل الذي يمتد لفئة عليا يمكن أن يكون شيئًا مثل:

1. class AbstracRxtEntityPersister extends RxEntityPersister
2. class AbstracReactivetEntityPersister extends ReactiveEntityPersister

هذا ليس متسقًا جدًا في المشروع الآن. في بعض الأحيان تستخدم الفصول
RxAbstractEntityPersister

أعتقد أنني سأستخدم الخيار 3: org.hibernate.reactive.ReactiveSession
لكنني سأنتظر لسماع ما إذا كانت هناك اقتراحات أفضل أو آراء قوية ضدها.

سأصوت أيضًا لـ 3 ، لكن ربما vietj لديه رأي أيضًا؟

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

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

يعجبني الخياران 2 و 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

دع اسم الحزمة ينقل أن الفئات "تفاعلية". إذا كان علينا إضافة Rx / Reactive كبادئة لجميع الفئات ، فهذا يجعل الفئات تبدو وكأنها مواطنين من الدرجة الثانية.

يتمثل الجانب السلبي الرئيسي الذي أراه في استخدام نفس اسم الفئة مثل النظراء غير التفاعليين إذا كنا نتوقع من المستخدمين استخدام كلا الفئتين في نفس الفئة (وبالتالي يتطلب الأمر أسماء فئات مؤهلة بالكامل في كل مكان يتم التعبير عن الأنواع) ، ولكن يجب ألا يستخدم AFAIK يحدث؟

يعجبني الخياران 2 و 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

FTR أنا موافق أيضًا على ذلك ، ومع ذلك ، أود أن أشير إلى أنه يزيد من مخاطر الخطأ عند الاستيراد التلقائي.

نظرًا لأننا في نهاية المطاف على يقين من أن لدينا نكهات متعددة لجلسة رد الفعل ، أود أن أقترح ما يلي:

• MutinySession للتمرد
• StagedSession أو شيء من هذا القبيل مقابل CompletionStage
• إلخ

WDYT؟

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

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

من بين واجهات برمجة التطبيقات "الرئيسية" ، ضع في اعتبارك مكافئات Query أيضًا.

للتسجيل ، أعتقد أن "Rx" لها حلقة لطيفة لها ، وهي ليست _ مملوكة_ لمشروع RxJava على الإطلاق - كما ذكرت أعلاه - لذا أود الاحتفاظ بالاسم لأن الآخرين لا يبدو صحيحًا.

على هيكل العقد

لا أحب التحميل الزائد لواجهة Session ، كما أشار Gavin ، فإنه يؤدي إلى أخطاء الإكمال التلقائي والحمل المعرفي الزائد للأشخاص.

لذا +1 لأي ​​من الأنماط التالية:

• MutinySession ، RxJava2Session ، JDKReactiveSession (لمرحلة الإكمال والتدفق)
• SessionMutiny ، SessionRxJava2 إلخ

النمط البديل هو reactiveSession.forMutiny().[...] ، reactiveSession.forJDK().[...] لكنه سيجعل كابوس التبعية جحيمًا على الأرجح. لا يبدو أن reactiveSession.unwrap(MutinySession.class) يحقق قيمة.

بعض النقاط الاضافية:

• يحتوي Rx على 3 إصدارات غير متوافقة ، لذا سيحتاج المرء إلى رقم الإصدار في العقد
• شقيق CompletionStage هو Flow لهذا السبب أطلقت عليه JDKReactiveSession
• يحتوي RxJava على عدة أنواع متعددة ومتعددة ، لذلك من المحتمل أن تكون كل طريقة RxJavaXSession "محملة بشكل زائد" مثل fetchAsSingle() إلخ.

أتخيل أن Query سيكون له أيضًا نظير تفاعلي. راجع للشغل حدث لي أن معلمات الاستعلام يجب أن تقبل كلاً من النوع المباشر والأغلفة التفاعلية مثل Uni<String>

على الاسم ، أعتقد أن Hibernate ORM Reactive لا بأس به hibernate-orm-reactive لكن FroMage ماذا عن "Panache Rx" هل يمر بتحويل مماثل؟

لاحظ emmanuelbernard أن الطريقة الحالية للحصول على Session و SessionFactory هي:

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

أنا سعيد إلى حد ما بهذا النمط.

JDKReactiveSession

قرف. يبدو هذا مروعًا لشيء من المحتمل أن نراه كثيرًا في الكود.

أتخيل أن Query سيكون له أيضًا نظير تفاعلي.

نعم ، إنه موجود بالفعل ويسمى حاليًا RxQuery . لكنها لا تفعل أي شيء في الوقت الحالي.

بصراحة ، يعجبني الخيار التالي بشكل متزايد:

//I want to try out Mutiny
Mutiny.SessionFactory sessionFactory = emf.unwrap(Mutiny.SessionFactory.class);
Mutiny.Session session = sessionFactory.openReactiveSession();
Mutiny.Query = session.createQuery(hql);

أو:

//I want to try it out with CompletionStage
Stage.SessionFactory sessionFactory = emf.unwrap(Stage.SessionFactory.class);
Stage.Session session = sessionFactory.openReactiveSession();
Stage.Query = session.createQuery(hql);

وبعد ذلك ، بمجرد التأكد من أنني أستخدم Mutiny ، يمكنني فقط كتابة:

import static org.hibernate.reactive.mutiny.Mutiny.*;

...

SessionFactory sessionFactory = emf.unwrap(SessionFactory.class);
Session session = sessionFactory.openReactiveSession();
Query = session.createQuery(hql);

أعتقد أن الطبقة الخارجية تخفف إلى حد كبير مشكلة تعطل الاستيراد التلقائي. (على الرغم من أن لها عيوبًا أخرى.)

التي تبدو رائعة gavinking

gavinking أنا أحب

أعتقد أن الطبقة الخارجية تخفف إلى حد كبير مشكلة تعطل الاستيراد التلقائي. (على الرغم من أن لها عيوبًا أخرى.)

على سبيل المثال؟

DavideD جيدا عيب واحد هو أن IDE لا تضيف عادة واردات ثابتة تلقائيا. (على الرغم من أنه يمكنك تكوينها للقيام بذلك.)

لاحظ emmanuelbernard أن الطريقة الحالية للحصول على Session و SessionFactory هي:

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

أنا سعيد إلى حد ما بهذا النمط.

JDKReactiveSession

قرف. يبدو هذا مروعًا لشيء من المحتمل أن نراه كثيرًا في الكود.

من معظم التعليقات التي جمعتها ، يكره الناس CompletionStage ويذهبون إلى RxJava أو الأصدقاء. لذلك سيكون هذا الإصدار هو اختيار الرجل الفقير.

من معظم التعليقات التي جمعتها ، يكره الناس CompletionStage ويذهبون إلى RxJava أو الأصدقاء. لذلك سيكون هذا الإصدار هو اختيار الرجل الفقير.

هل تحاول التأكد من عدم وجود فرصة لاستخدامه؟ :-د

من معظم التعليقات التي جمعتها ، يكره الناس CompletionStage ويذهبون إلى RxJava أو الأصدقاء. لذلك سيكون هذا الإصدار هو اختيار الرجل الفقير.

بالتأكيد ، أنا أكره ذلك أيضًا.

لا تضيف IDE عادةً عمليات استيراد ثابتة تلقائيًا

هذه نقطة قوية جدًا ضدها ، حيث لا يمكنك كتابة Session والحصول على اقتراح IDE لاستيراد static Mutiny.Session ، لذلك عليك دائمًا كتابته مسبوقة Mutiny.Session . وسيتعين على جميع المستندات تضمين عمليات الاستيراد أيضًا ، مما يجعل من الصعب نسخها / لصقها.

على الاسم ، أعتقد أن Hibernate ORM Reactive لا بأس به في حالة السبات أو رد الفعل ولكن FroMage ماذا عن "Panache Rx" هل يمر بتحويل مماثل؟

نعم فعلا. لقد كان دائمًا اسمًا رمزيًا.

هذه نقطة قوية جدًا ضدها ، حيث لا يمكنك كتابة الجلسة والحصول على اقتراح IDE لاستيراده

لا أشعر أنه بهذه القوة: لا يزال بإمكانهم كتابة Mutiny.SessionFactory ، كما يجب أن نلتزم على الأرجح في الوثائق (لذلك لن نضطر إلى تضمين الواردات ، على الرغم من أنه ربما يجب علينا دائمًا كقاعدة عامة) .

FroMage ليس بهذا السوء. في intelliJ ، انتقل إلى Settings> Code Style> Java> Imports . في Eclipse هناك شيء مشابه.

لما يستحق ، يجب اعتبار Mutiny واجهة برمجة التطبيقات الافتراضية في رأيي. يمكن أن يقع الباقي ضمن حزمة compat . حتى الإصدار CompletionStage/Flow :-)

تحديث: بالنظر إلى مستندات Mutiny ، هل من المنطقي حتى أن تخبز في التوافق؟ ما عليك سوى الاعتماد على Mutiny لذلك ، ووضع العبء (الصغير نوعًا ما) على المطور للقيام بالتحويل إذا احتاج إلى التحويل من واحد إلى الآخر.

• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_completionstages
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_rx_java_2
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_reactor

يضيف Clement الترامبولين إلى Mutiny ، وقد يكون حجة داعمة أخرى لجعل Mutiny افتراضيًا لـ Reactive Hibernate.

تطور هذا النقاش في القائمة البريدية لتطوير السبات. يبدو أننا جميعًا نميل إلى استخدام Hibernate Reactive ... حسنًا؟

سيكون من الأفضل الرد على القائمة البريدية.

تذكير ، للتسجيل انظر:

• https://lists.jboss.org/mailman/listinfo/hibernate-dev

هذا على وجه التحديد هو الخيط الكبير المتعلق بهذه المشكلة (من بين أشياء أخرى):

• https://lists.jboss.org/pipermail/hibernate-dev/2020-May/018774.html

رد الفعل السبات ، حسنًا؟

:شامبانيا:

هذا على وجه التحديد هو الخيط الكبير المتعلق بهذه المشكلة (من بين أشياء أخرى):

يا له من موضوع مهم ، هناك بريد إلكتروني واحد ؛)

أنا شخصياً ما زلت أحب HibernateRX بشكل أفضل - أوافق مع Sanne على أن RxJava لا تمتلك "Rx" وأن IMO HibernateRX هو اسم جذاب. يبدو رد الفعل Hibernate أشبه بوصف أكثر من كونه اسمًا. فقط $ 0.02 الخاص بي ولم أرغب في ازدحام سلسلة الرسائل البريدية مع هذا.

أنا شخصياً ما زلت أحب HibernateRX بشكل أفضل - أوافق مع Sanne على أن RxJava لا تمتلك "Rx" وأن IMO HibernateRX هو اسم جذاب. يبدو رد الفعل Hibernate أشبه بوصف أكثر من كونه اسمًا. فقط $ 0.02 الخاص بي ولم أرغب في ازدحام سلسلة الرسائل البريدية مع هذا.

تكمن المشكلة في aguibert في أنه ما الذي
الامتداد التفاعلي هو شيء محدد https://en.m.wikipedia.org/wiki/Reactive_extensions

صحيح ، أعتقد أن Hibernate Rx ستقف فقط على "Hibernate React Extensions". الامتدادات التفاعلية هي شيء محدد ، لكنها تشير إلى مفهوم ، وليس منتجًا أو مشروعًا معينًا. IMO ما نقوم به هنا لا يزال يناسب هذا المفهوم.

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

سأغلق هذا لأنه لم يكن هناك تمرد كنتيجة من البريد الإلكتروني لإيمانويل في القائمة البريدية :)

Hibernate Reactive إنه كذلك! شكرا مرة أخرى مورفي والجميع

تليها # 111