Serviceを読んで理解し、同意したものとみなします。すべて1jpa検索機能作成ぱっと見での回答になりますが、1つ目のSQL(getEmployeesName)で複数件のレコードが取得できるのに対し、それらのレコードを検索条件にする2つ目のSQL(getCreateUser)は1件しか想定していないWHERE句(=での比較)になっています。ようにしなければ、動作しないと思います。個の銅バッジ1JPAプロジェクトにおいてRepositoryファイル作成時にビルドエラーが起きるもともとDB操作をやりたかったSpringBootのプロジェクトはまた別にJPAプロジェクトを新規作成し、Repositoryファイルを作成していたため、上記のエラーが出ておりました。本などを参考にして、もともとのSpringBootプロジェクト内にReposirotyファイルを作成して同様に記述したところ、エラーは発生しなくなりました。supaさん、解決時の対処についてご指摘ありがとうございます。自分のコメントだと48時間後でないと解決済みマークができないようなので、後日解決済みにします。自動生成されるエイリアス名がアンダースコア始まりになるが、利用しているDBMSでは命名違反になるのでなんとかしたい、ということだと理解しました。現行バージョンでは対処不能かなと考えます。私も最近エイリアス絡みの不具合を踏んで似たような内容を調べていました。org.hibernate.mapping.Column#getAliasメソッドになります。生成するエイリアス名の命名戦略は固定でありコンフィグ等で変えられる余地はありません。getNameメソッドに対応するgetQuotedNameメソッドが存在しますが、エイリアスについて対応するメソッドが無いのでクオートする仕組みが無いと予想します。動作確認してませんが、こんな実装で取得したdatabaseProductNameで判別できないでしょうか。値をtureに設定すれば解決するとおもいます。個の銅バッジ1JPAでデッドロックを検出する方法EclipseLinkから呼び出される各RDBMS用のJDBCドライバーの実装(どの例外を返すか)に依存しますが、SQLTransactionRollbackExceptionをcatchするようにしておけば、いいと思います。5.1.73の場合は、これを継承するMySQLTransactionRollbackExceptionがスローされました。実際にデッドロックを起こすコードを書いて実験してみると、分かります。例外処理はこんな感じでしょうか。JPAで分割されたテーブルにアクセスするベストプラクティスな実装方法が知りたいDBからのアプローチですが、同じ構造のテーブルであれば、UNIONしたVIEWを用意する方法があると思います。以下のようなVIEW「user」を作れば、entityもrepositoryも1つで十分になると思います。個の銅バッジ1一時的にユニーク制約を違反してしまう場合のベストプラクティス一つの考えですが、ユニーク制約の場合はNULLを持つこと許容します。対応できるかもしれません。INDEXの作り直しになるのである程度の負荷が予想されます。それは避けられるかと。今回の場合は2行についてDELETE、INSERTでもいいかもしれません。IDにインデックスがなければそのほうが手間もシステム負荷も少ないと思います。個の銅バッジ1一時的にユニーク制約を違反してしまう場合のベストプラクティス3通り考えられます。テーブルXを正規化して、データを持つテーブルXDATAと各行の順序を表すXORDERテーブルに分離する。XORDERはORDERとXDATAの行IDから構成し、ORDERのみユニークキーとすれば、順序の入れ替え時にID列を書き換えても一意性制約違反にならない。テーブルXのORDER列の一意性制約は外し、アプリケーションでユニークになるよう制御する。順序を入れ替える2行を両方削除してORDERの内容を入れ替えて挿入しなおす。1はきれいと思います。SQLで書く場合、2テーブル結合することになるので、面倒かも知れません。2はテーブルを操作するのがアプリケーションだけであれば、よく取られる手法かと思います。メソッドをオーバーライドするのは簡単なように思えますが、間違ったやり方でオーバーライドしてしまう方法はたくさんあり、その結果は悲惨なものになります。問題を避ける最も簡単な方法は、equalsメソッドをオーバーライドしないことです。オーバーライドするのが適切でしょうか。個の銅バッジ1JPAのエンティティにはequalsとhashCodeを実装すべきか?まず、equalsとhashCodeのオーバーライドが重要になってくるのは、主にオブジェクトをSetやMapといったコレクションに入れる場合です。コレクションの内部処理がequalsとhashCodeに依存しているためです。エンティティオブジェクトをコレクションに入れたり、比較したりする必要がないのなら、equalsとhashCodeのオーバーライドが必要というわけではないでしょう。このようなことはしてくれないと思います。APIリファレンスにもそんなことは書いてありませんし。この記事を読むと以下の様な見解になります。エンティティクラスではequalsとhashCodeをオーバーライドするのがベストプラクティスです。fetchしてるのにcountQueryが未指定なのが原因だと思います。利用してエンティティBをfetchする際は、Bエンティティがフィールドc(に対応するカラムc_unique_id)に持っているCのPK(@Idアノテーションが付いているフィールド)をキーとして利用しようとします。イメージとしては次のようなSQLでしょうか。個の銅バッジ1左外部結合がうまくいきません。