JPAとプレーンJDBC DAOの実装を混在させるとどのような問題が発生する可能性がありますか？

Question

異なる技術を使用して同じデータベースにアクセスする2つのチームがあります。 1つはJPA（Hibernate、具体的には）です。もう一方はプレーンJDBCを使用します。

私は、各チームが各テクノロジーのデフォルト設定やベストプラクティスを使用していることを前提に、懸念事項のリストを作成するように求められました。

これは新しいデータベースです。スキーマがJPAチームだけで設計されているとか、JDBCチームだけで設計されているとしたら、どちらもそのスキーマにアクセスしようとしています。

あなたはあなたの経験を教えていただけませんか？

更新日：私はここで意見を求めていません。私はJPAかJDBCが "より良い"かどうかは気にしません。私は、2つの技術を混在させる際の相互運用性の問題の客観的なリストを求めています。

シナリオ：ここ

---

は私が探しているものの一例であるユーザーは、行を読み込み、メモリにそれを修正し、それをデータベースに戻って保存します。

• JPAがオプティミスティック・ロックを使用する場合、各表にversion列を追加します。
• トランザクションがコミットされると、JPAは、行が読み取られた時刻と更新された時刻の間でバージョンが変更されたかどうかを確認します。バージョンが変更された場合、例外がスローされます。そうでなければ、コミットを続行できます。
• JDBC実装でテーブルロック（a.k.a.pessimistic locking）を使用する場合は、SELECT ... FOR UPDATEを使用して同時更新を防止します。

• JDBCの実装は、JPAの大会を認識していないとコミットのversionを更新しないとどうなるか想像してみて：

  1. JPAはSELECTを使用して行を読み取り、JDBCを読み込む1.
  2. に等しいversionを見て行はSELECT ... FOR UPDATEを使用しています。
  3. JDBCは、versionをインクリメントせずに行を更新します（トランザクションをコミットします）。
  4. JPAは行を更新しようとします。 versionはまだ1に等しいので、コミットは完了します。
  5. JPA（手順4）がJDBCの更新を邪魔しました（手順3）。

レッスンは学んだ：JDBCの実装はversion列を更新するために知っておく必要があります。

Answer 1

他の人が答えるのを待っている間に自分のリストを作成する：

1. JPAは、デフォルトでは楽観的ロックを使用しています。これには、バージョン列を追加し、行が更新されるたびに増分する必要があります。 JDBCは同じことをしなければならないでしょう。
2. ダイバージェントDAOレイヤーは、末尾のモデルで終わる可能性が高くなります。つまり、JPAマッピング構成が変更されると、対応するJDBCコードが黙って壊れる可能性があります。
3. JPAがカスケード・ルールを使用して更新または削除を伝播する場合。 JDBCも同じことをやっています。
4. JPA @Id @GeneratedValue(strategy=GenerationType.SEQUENCE)を使用する場合は、シーケンステーブル（例：hibernate_sequence）を作成して使用します。 JDBCは同じことをしなければならないでしょう。
5. JDBCはJPAクラスの継承テーブルをサポートする必要があります。
6. JPAがスキーマの進化を推進する場合、JDBCの実装では、その規約/機能のサポートを追加する必要があります。一方、JDBCがスキーマの進化を推進する場合、スキーマに影響するJPA機能を無効にする必要があります。データはJPA（crizzisの礼儀）の外に変更された場合
7. は