私は大規模なデータベース操作を「トランザクション化」していますが、MQL アプローチを使用せずに休止状態で SQL クエリを実行すると、データベースのビューが正しく表示されないというこの問題に遭遇しました。具体的には、コードはほとんどの場合、より適切な方法で休止状態を使用しますが、誰かが単に sql を実行することにした場所があります。彼らがこれをしたのは好きではありませんが、現時点では「それはそれです」.
それを説明しているように見える説明を見つけましたが、すべての例は実際にコードでトランザクションを取得および管理しています。クラス全体で @TransactionAttribute アノテーションを使用してこのコードを変更し、この動作が発生する多くの場所を見つけていますが、説明が単にアノテーションでラップされたコードに適用されるとは完全には確信していません-私は仮定していました休止状態マネージャーを使用するものはすべて、セッション内のオブジェクト キャッシュに依存します。
間違った用語などで休止状態の概念を参照している場合は、事前に謝罪してください。
実際、Chris Landryによる「説明」ブログにはSQLQueryの3つの重要なAPIメソッドがありません。それが、彼がこれらの問題を抱えている理由です。具体的には、（1）addSynchronizedQuerySpace、（2）addSynchronizedEntityName、および（3）addSynchronizedEntityClassです。
パルテノンが指摘しているように、SQLクエリ文字列自体に基づいているだけでは、Hibernateはクエリでクエリされているテーブルやエンティティを知る方法がありません。したがって、セッションでキューに入れられた変更をデータベースにフラッシュする必要があるかどうかはわかりません。ブログでChrisは、SQLクエリを実行する前に自分でflush（）呼び出しを実行できることを指摘しています。ただし、私が説明しているのは、Hibernateの自動フラッシュ機能です。実際には、HQLクエリとCriteriaクエリに対して同じことを行います。影響を受けるテーブルを知っているのはそこだけです。とにかく、この自動フラッシュのプロセスは、クエリに影響を与えるものだけを「最小限のフラッシュ」でフラッシュします。そこで、これらの方法が役立ちます。
例として、ChirsのSQLクエリは
session.createSqlQuery("select name from user where name = :userName")
本当に彼がする必要があるのは言うことだけでした...
session.createSqlQuery("select name from user where name = :userName")
.addSynchronizedQuerySpace( "user" )
はaddSynchronizedQuerySpace( "user" )、クエリが「user」という名前のテーブルを使用していることをHibernateに伝えています。これで、Hibernateは、そのユーザーテーブルにマップされたエンティティに対して保留中のすべての変更を自動フラッシュできます。
あなたの質問は紛らわしいですが、ネイティブクエリを実行しているときにHibernateがセッションキャッシュ内のエンティティを探していないと言っていると思います.
SQL クエリ、またはネイティブ クエリは、Hibernate がデータベースにリレーするだけのクエリです。Hibernate はクエリを解析せず、結果も解析しません。ただし、Hibernate では結果を処理して、列をクラスのプロパティに変換できます。そうは言っても、ネイティブ クエリがセッション キャッシュをバイパスするのは当然のことのように思えます。これは、Hibernate がクエリについても、このクエリの「結果」(その時点ではオブジェクトではない) についても何も知らないためです。