なぜにbuildSessionFactory()
置き換えられるのbuildSessionFactory(ServiceRegistry)
ですか?ServiceRegistryの重要性は何ですか?
1 に答える
この理由は、Hibernate の Jira で説明されています。
https://hibernate.onjira.com/browse/HHH-2578
現在、SessionFactory は、一連のものを Configuration オブジェクトに投入し、攪拌し、沸騰させてから、SessionFactory を引き出すことによって構築されます。深刻なことに、構成内での現在の操作方法と、それを使用して SessionFactory を構築する方法には、いくつかの問題があります。さまざまな情報が利用可能になる「ライフサイクル」がないという一般的な問題。これは多くの点で重要な省略です: 1) スキーマの生成を検討してください。現在、多くの db オブジェクト名が決定されているときに、方言を知ることさえできません。たとえば、方言のキーワード/予約語でもあるテーブル/列名を透過的に処理できるため、これは素晴らしいことです。2) 型の静的性と型マッピング。現在、それらをスコープするものが何もないためです。理想的には、型インスタンスは、それがバインドされている SessionFactory を認識しています。代わりに、API メソッドを何度も変更して、SessionFactory が必要であることが判明したときに渡されたパラメーターとして追加する必要があります。3) また、Hibernate の「静的」構成パラメーターのほとんど (すべて?) は、これらの静的型内から使用されるため、現在そうする必要があります。したがって、スコープ タイプを使用すると、これらの構成パラメーター (バイトコード プロバイダー、バイナリ ストリームの使用など) のスコープも設定できます。理想的には、ユーザーが org.hibernate.cfg.Settings (または類似のもの) インスタンスを自分で構築するスキームが起こっていると思います。さらに、何らかのレジストリにメタデータを適用します (ここでは MetadataRegistry と呼びましょう)。次に、SessionFactory を構築するために、これら 2 つの情報を提供します (ctor を介して? builder を介して?)。ただし、重要な側面は、MetadataRegistry の情報がその時点まで処理されないことです。これにより、スキーマ オブジェクトの名前、型などを解決すると、ランタイム設定 (特に方言) にアクセスできることが保証されます。
これに関するコメントも読むことができます: https://hibernate.onjira.com/browse/HHH-7580 貼り付けをコピーするには多すぎるため、Jira はダウンしないので、この回答は有効なはずです。