問題タブ [cascade]

通常の Foo エンティティがあり、persist(foo) を呼び出すと、エンティティに @Id が自動的に設定されます。ただし、上記の Foo エンティティに Bars のコレクションがバインドされている場合は、

新しい Bar を作成して foo の Bars コレクションに追加し、merge(foo) を呼び出すと、作成したばかりの Bar は永続化されますが、その @Id は更新されません!

後で find(Foo.class, foo.getId()) を呼び出さずに、この ID を取得する方法はありますか?

多対1の関係を持つ「子」と「親」の2つのテーブルがあるとしましょう。親レコードが削除された場合、子エントリを削除する必要があります。

parent.hbm で 1 対多の関連付けを作成し、cascade="all-delete-orphan" を設定して、親から子テーブルをリンクしても問題ありません。

問題は、親側で 1 対多の関係を望んでいないため、子側で多対 1 を作成したことです。その理由は、子テーブルがかなり大きく、親を使用するたびに何百ものレコードを抽出したくないからです。したがって、私の構成は次のようになります。

child.hbm:

一方、parent.hbm には子との関連付けはありません。

問題は次のとおりです。子が多対1で親にリンクされている場合、親を削除するときにHibernateに子テーブルからレコードを削除させる方法は?

ありがとう。

すべての変更を監視し、すぐに問題のオブジェクトを永続化することで、オブジェクト モデルをデータベースと同期させるアプリケーションを作成しようとしています。モデル内のオブジェクトの多くは、大きなリストまたはツリーに子を持っています。

データベースからオブジェクトをロードするときは、一方向のカスケード関係に依存して、そのすべての子も取得し、アプリケーションに含めます。

ただし、永続性を必要とする親オブジェクトのフィールドを変更することは可能であり、影響を受ける子はないと判断できます。したがって、カスケードされたすべての子が永続化された状態でデータベースにアクセスすることなく、親を永続化したいと考えています。

例えば

親オブジェクトを永続化するときにカスケード オプションをオーバーライドするにはどうすればよいですか? それとも、単に REFRESH に設定して、カスケード永続化が不要であることを確認する必要がありますか?

たとえば、「RealEstate」と「Picture」という 2 つのエンティティがあります。RealEstate は、Picture のコレクションを保持します。マッピング ファイルの RealEstate には Pictures のバッグがあり、cascade は Delete です。

RealEstate を削除すると、関連するすべての写真が削除されます。しかし、カスタム メソッドを実行して Web サーバーから写真を削除する方法はありますか。

私は割り当てることによってそれをcascade="none"行い、RealEstate を削除するときに、最初にそれに関連する写真があるかどうかを確認し、ある場合はそのDeletePicture()メソッドを呼び出します。

このような状況であなたは何をしますか？

コンポーネントのデータベースがあります。各コンポーネントは特定のタイプです。つまり、コンポーネントと型の間には多対 1 の関係があります。タイプを削除するとき、そのタイプの外部キーを持つすべてのコンポーネントを削除したいと考えています。しかし、私が間違っていなければ、カスケード削除はコンポーネントが削除されたときに型を削除します。私が説明したことを行う方法はありますか？

パフォーマンスが重要です: データベース内で削除/更新をカスケードするのと、Hibernate/JPA に任せた方が良いですか?

カスケードが DBMS 内にある場合、これはデータのクエリ機能に影響しますか?

それが重要な場合、私はHSQLDBを使用しています。

データベース テーブルの大部分が他の 1 つのテーブルと強い関係を持つアプリケーションがあります。現在、外部キーを使用して参照整合性を強制していますが、これが本当に最善のアプローチであるかどうか疑問に思っています。プライマリ テーブルのデータは、ビジネス ユーザーが管理インターフェイスから削除できます。つまり、カスケード削除を実行する (または複数の削除ステートメントを記述する) 必要がありますが、他のすべてのデータを本当に削除する必要があるかどうかはわかりません。同時に。それは、後日役に立つ*かもしれない*多くのデータである可能性があります (おそらく報告しますか?)。ただし、二次テーブルのデータは、基本的に、一次テーブルとの関係が存在しない限り、アプリケーション自体には役に立ちません。

私は2つのテーブルを持っています。これらのテーブルには、それらの間に 2 つの関係があります。

この 2 つの関係が存在します。

私の質問は、テーブル 1 の一部の行を削除する必要があるということです。現在行っているのは、

table2 で ON DELETE SET NULL を使用できることはわかっています。そうすれば、ID_XPTO2 で null 値を持つすべての行を検索して削除できますが、DBA はそれを使用したくありません。

このプロセスを実行するためのより良い解決策はありますか?

SQL Server 2005 でこれを回避する方法はありますか?

（それは私を悩ませます、そして私がそれに遭遇するたびに私はストロップに陥ります.しかし、これは私が対処しなければならず、スタックオーバーフローに参加したのはこれが初めてです.私が持っている小さな正気を保存してください！）

DimensionTable:
id INT IDENTITY(1,1)

FactTable:
source_id INT NOT NULL、
target_id INT NOT NULL

「Fact.source_id」から「Dimension.id」への外部キーを作成し、カスケード削除とカスケード更新で設定しました。

「Fact.target_id」で同じことをしようとすると、カスケードがたどるパスが複数あるため、「ああ、いや、いや」というエラーが表示されました。

ここには他の外部キーは含まれていません。作成したいのは 2 つだけです。カスケードなしで 2 番目の外部キーを作成することはできますが、それは私にはかなりうんざりするようです。これは、手動で維持される一連のテーブルです (それらに触れることはめったにないため、クライアントはこれを行うために GUI に料金を支払う必要はありません)。このようなカスケードの削除/更新は非常に便利ですが、両方のフィールドにある場合。(私は一貫性が苦手です)

****泣き言****

Lesson私は:
列: ...と呼ばれるデータベーステーブルを持っています[LessonID, LessonNumber, Description]...さらにいくつかの他の列

と呼ばれる別のテーブルがありますLesson_ScoreBasedSelection：
列： [LessonID,NextLessonID_1,NextLessonID_2,NextLessonID_3]

レッスンが完了すると、そのレッスン ID がLesson_ScoreBasedSelectionテーブルで検索され、次の 3 つの可能なレッスンが取得されます。各レッスンは、特定の範囲のスコアに関連付けられています。スコアが 0 ～ 33 の場合、NextLessonID_1 に格納されている LessonID が使用されます。スコアが 34 ～ 66 の場合は、NextLessonID_2 に格納されている LessonID が使用されます。

テーブル内のすべての値が Lesson テーブルの LessonID 列にエントリを持っている必要があるLesson_ScoreBasedSelectionため、lesson テーブルの LessonID 列を参照する外部キーを使用して、テーブル内のすべての列を制約したいと考えています。Lesson_ScoreBasedSelectionまた、カスケード更新をオンにして、Lesson テーブルで LessonID が変更された場合に、テーブル内のすべての参照Lesson_ScoreBasedSelectionが更新されるようにします。

この特定のカスケード更新は非常に単純な一方向の更新のようにLesson_ScoreBasedSelection見えますが、Lesson テーブルの LessonID フィールドを参照するテーブルの各フィールドに外部キー制約を適用しようとすると、次のエラーが発生します。

テーブル ' ' に FOREIGN KEY 制約 'c_name' を導入Lesson_ScoreBasedSelectionすると、サイクルまたは複数のカスケード パスが発生する可能性があります。

このエラーが発生する理由、または説明した制約とカスケード更新を実現する方法を誰かが説明できますか?