Hibernate-reactive: 「Rx」名を再検討してください

@emmanuelbernard WDYT？

ええ、それは常にコードネームでした。

それでは、本名に固まるまでの道のりなので、すぐに変更したほうがいいです。

私はそれを私に割り当てました。 誰かが異議を唱えない限り、私は週末にそれをするつもりです。

私は週末にそれをするつもりです

しかし、あなたはそれを何に変えるつもりですか？

hibernate-reactiveはそれほど悪くは聞こえません

>>

+1して休止状態に反応する

7:45 DavideDのでは水、2020年4月1日に[email protected]書きました：

hibernate-reactiveはそれほど悪くは聞こえません

>>

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
。

それは問題ありませんが、 ReactiveSessionを1000回入力したくありません。

私はHibernateRXが好きです。「反応的」であることは概念であり、RxJavaの商標ではありません。

それは問題ありませんが、ReactiveSessionを1000回入力したくありません。

タイプ？ キーボードにスペースボタンがありませんか？ :)

公平を期すために、クラス名にプレフィックスを使用することはあまり好きではありません。 パッケージに入れるだけで十分でしょうか？ それとも、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

他に何か提案はありますか？

私は強い好みはありません。 Reactiveは名前を読みやすくし、それほど長くはないと思います。 スーパークラスを拡張する実装またはクラスによっては、次のようになる可能性があるため、プレフィックスは必要ないことに注意してください。

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それでも問題ありませんが、自動インポート時にエラーが発生するリスクが高くなることに注意してください。

最終的には、複数の種類のリアクティブセッションがあることがほぼ確実であることを考えると、次のことを提案したいと思います。

• Mutinyの場合はMutinySession
• StagedSessionまたはCompletionStageようなもの
• NS

WDYT？

これは、リアクティブタイプのフレーバーを公開する唯一のユーザー向けAPIですか？

これは、リアクティブタイプのフレーバーを公開する唯一のユーザー向けAPIですか？

「メイン」APIの中で、 Query相当するものも検討してください。

ちなみに、「Rx」にはいいリングがあると思います。前述したように、RxJavaプロジェクトによって「所有」されているわけではないので、他の人が正しく聞こえないため、名前を付けておきたいと思います。

契約構造について

Gavinが指摘したように、 Sessionインターフェースのオーバーロードは好きではありません。これは、オートコンプリートエラーと人々の認知的オーバーロードにつながります。

したがって、次のパターンのいずれかに対して+1します。

• MutinySession 、 RxJava2Session 、 JDKReactiveSession （CompletionStageおよびFlowの場合）
• SessionMutiny 、 SessionRxJava2など

代替パターンはreactiveSession.forMutiny().[...] 、 reactiveSession.forJDK().[...]が、依存関係の悪夢の地獄になる可能性が最も高くなります。 reactiveSession.unwrap(MutinySession.class)は価値をもたらさないようです。

いくつかの追加ポイント：

• Rxには互換性のない3つのバージョンがあるため、契約にバージョン番号を含める必要があります
• CompletionStageの腕の兄弟はフローです。だから私はそれをJDKReactiveSessionと呼びました。
• RxJavaには複数のタイプと単一のタイプがいくつかあるため、各RxJavaXSessionメソッドは「オーバーロード」される可能性があります（例： fetchAsSingle()など）。

Queryにもリアクティブな対応物があると思います。 ところで、クエリパラメータは直接型とリアクティブラッパーの両方を受け入れる必要があることに気づきました（例： Uni<String>

名前からすると、Hibernate ORMReactiveはhibernate-orm-reactive問題ないと思いますが、 @ FroMageは「

@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の欠点の1つは、IDEが通常静的インポートを自動的に追加しないことです。 （ただし、それを行うように構成することはできます。）

@emmanuelbernardは、 SessionとSessionFactoryを取得する現在の方法は次のとおりであることに注意してください。

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

私はこのパターンにかなり満足しています。

JDKReactiveSession

うーん。 これは、コードで頻繁に見られる可能性のあるものにとっては恐ろしいことのように見えます。

私が集めたフィードバックのほとんどから、人々はCompletionStageを嫌い、RxJavaや友達を探しに行きます。 そのため、そのバージョンは貧乏人の選択になります。

私が集めたフィードバックのほとんどから、人々はCompletionStageを嫌い、RxJavaや友達を探しに行きます。 そのため、そのバージョンは貧乏人の選択になります。

使用される可能性がないことを確認しようとしていますか？ ：-NS

私が集めたフィードバックのほとんどから、人々はCompletionStageを嫌い、RxJavaや友達を探しに行きます。 そのため、そのバージョンは貧乏人の選択になります。

確かに、私もそれが嫌いです。

IDEは通常、静的インポートを自動的に追加しません

それはあなたが書くことができないということ、それに対してかなり強力なポイントだSession 、インポートするIDEの提案を取得static Mutiny.Sessionあなたは常に先頭にそれを入力する必要がありますので、 Mutiny.Session 。 また、すべてのドキュメントにインポートも含める必要があるため、コピー/貼り付けが困難になります。

名前からすると、Hibernate ORM Reactiveは素晴らしいhibernate-orm-reactiveだと思いますが、 PanacheRx 」について同様の変換を行いますか？

はい。 それは常にコードネームでした。

これは、Sessionを記述して、インポートするIDEプロポーザルを取得できないというかなりの強みです。

私はそれがそれほど強いとは感じていません：おそらくドキュメントに固執する必要があるように、彼らはまだMutiny.SessionFactory書くことができます（したがって、原則として常にそうすべきかもしれませんが、インポートを含める必要はありません） 。

@FroMageそれはそれほど悪くはありません。 intelliJで、 [設定]> [コードスタイル]> [Java]> [インポート]に移動します。 Eclipseにも似たようなものがあります。

私の意見では、MutinyはデフォルトのAPIと見なされるべきです。 残りはいくつかの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をReactiveHibernateのデフォルトにするためのもう1つの支持的な議論かもしれません。

この議論は、hibernate-devメーリングリストで発展しました。 私たちは皆、 Hibernate Reactive行く傾向があるようです...わかりましたか？

メーリングリストに返信するのが最善でしょう。

リマインダー、登録するには、以下を参照してください。

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

具体的には、これはこの問題に関連する大きなスレッドです（とりわけ）：

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

Hibernate Reactive、いいですか？

：シャンパン：

具体的には、これはこの問題に関連する大きなスレッドです（とりわけ）：

なんて大きなスレッドなのか、1通のメールがあります;）

個人的には、HibernateRXの方が好きです。RxJavaが「Rx」を所有しておらず、IMOHibernateRXがキャッチーな名前であることにSanneと同意します。 Hibernate Reactiveは、名前というよりも説明のように見えます。 私の0.02ドルだけで、これでメーリングリストのスレッドを乱雑にしたくありませんでした。

個人的には、HibernateRXの方が好きです。RxJavaが「Rx」を所有しておらず、IMOHibernateRXがキャッチーな名前であることにSanneと同意します。 Hibernate Reactiveは、名前というよりも説明のように見えます。 私の0.02ドルだけで、これでメーリングリストのスレッドを乱雑にしたくありませんでした。

@aguibertの問題は、HibernateRx名でxが何を
リアクティブエクステンションは特定のものですhttps://en.m.wikipedia.org/wiki/Reactive_extensions

そうです、HibernateRxは単に「HibernateReactiveExtensions」の略だと思います。 Reactive Extensionsは特定のものですが、特定の製品やプロジェクトではなく、概念を指します。 私たちがここで行っているIMOは、依然としてその概念に適合しています。

「HibernateReactive」という名前でこれまでにないほどコンセンサスに近づいているように見えるので、私もその名前でまったく問題ありません。

メーリングリストのエマニュエルの電子メールの結果として反乱がなかったので、これを閉じます:)

Hibernate Reactiveです！ もう一度@murphyeとすべてに感謝します

フォローアップ＃111