Hibernate：削除の前に外部キー制約違反をチェックしますか？

Question

私が現在取り組んでいるシステムでは、関係のないオブジェクトは自由に削除できますが、論理的に削除する必要があるというポリシーがあります。履歴情報が削除されないようにするためのものです。

基本的に、私がやっていることは、オブジェクトのキーが現在別のテーブルに存在するかどうかを判断することでした。そうでない場合は、単にdelete（）を呼び出します。それ以外の場合は、論理的な削除を示すプロパティを設定し、update（）を呼び出します。

私はSpringトランザクション管理を使用していますので、できるだけセッション自体を混乱させようとしています。 Hibernateの例外は致命的で

@Transactional 
public void deleteObject(SomeEntity object) 
{  
    //try to delete 
    this.someEntityDAO.delete(object); 

    try //force foreign key constraint check 
    { 
     this.someEntityDAO.flush(); 
    } 
    catch (ConstraintViolationException e) 
    { 
     //reload object 
     object= this.someEntityDAO.loadById(object.getId()); 

     //save as inactive instead of deleting 
     object.setActive(false); 
     this.someEntityDAO.update(object); 
    } 
} 

ので、これは完全に信頼できない（それが動作するにもかかわらず）：私の最初のアプローチは、最初に動作するように見えますが、あなたはそれが大きな欠陥を持っていることがわかります。実際に操作を実行することなく（したがってセッションを無効にすることなく）、制約のために削除が失敗するかどうかをテストできる一種の「ピーク」操作を行う方法があるかどうか疑問に思っていました。私が考えることができるのは、関連する各テーブルを手動でチェックしてIDが存在するかどうかを確認することですが、これは非常に退屈で、多くの関係があるテーブルではエラーが発生しやすくなります。可能であれば、データベースに既に存在する制約を活用したいと思います。

Answer 1

に特異的に言えば：したがって、基本的

、私がやろうとしたものをオブジェクトのキーは、現在、別のテーブルに存在するかどうかを決定しました。そうでない場合は、単にdelete（）を呼び出します。それ以外の場合は、論理的な削除を示すプロパティを設定し、update（）を呼び出します。

と：

削除が実際に実行せず、原因の制約に失敗する場合、私はテストすることができている「PEEK」操作の並べ替えを行う方法がある場合、私は思っていました（したがって、セッションを無効にする）。

私は時々Hibernateでしか動作しませんでしたが、一般的な答えは次のとおりです。これはSQLのためのものです。それはあなたのwhere句のすべてです！

分かりやすくするために、トランザクション自体のチェックで十分なwhere句を使用して削除します。 deleteは、与えられた制約を満たすものを削除します。

更新：

あなたが書いた：

は「だから、基本的に、私は何をしようとしていたことは、オブジェクトのキーは、別のテーブルに現在存在しているかどうかを判断したことがない場合。私は単純にdelete（）を呼び出します。それ以外の場合は、論理的な削除を示すプロパティを設定し、update（）を呼び出します。

問題は、SQLでデータベースエンジンに任せて（直接）する必要がある場合に問題が発生することです。 "存在しない"節の使用を調べてください...