問題タブ [cascading-deletes]

コード ファーストを使用して、テーブルで CASCADE DELETE を有効にしたいと考えています。モデルをゼロから再作成すると、関係が自動的に設定されても、CASCADE DELETE は設定されません。奇妙なことは、多対多の関係を持つ一部のテーブルでこれを有効にしていることです。これには問題があると思われます。

セットアップ: テーブル A <- テーブル B.

テーブル B の FK は、テーブル A の PK を指します。

なぜこれがうまくいかないのでしょうか？

私の質問は次のとおりです。DogインスタンスD、OwnerインスタンスO、SitterインスタンスSを作成し、DをOとSの両方に関連付けると、Sが削除されるとOはどうなりますか？OはまだDを持っているでしょうか？カスケード削除なので、SとDの両方が削除されますよね？Oはいつどうなりますか？それはまだDを持っていますか？

Oracleのツリーを含むテーブルがあります。

ツリーのルートに親がない場合、カスケード削除を追加するにはどうすればよいですか？

現在、ルートの親IDは-1に設定されています。これを試してみると、次のエラーが発生します。

カスケード削除なしで双方向1：Nアソシエーションで親オブジェクトを削除できるかどうか知りたいのですが。によると

http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20%28GORM%29.html

...一方向の関係では、親の端は「save-update」でマップされ、子の端は「none」でマップされます。双方向の関係でこれらの設定を試しましたが、それほど驚くことではありませんでした。具体的には：

そして、これがプロジェクトクラスです。

これに対する解決策がある場合は、アプリケーションを再設計したくありません（Projectクラスから「belongsTo」を削除します）。両端からのナビゲーションアクセスは非常に便利で、プロジェクト側にはあまり多くのインスタンスがありません。

また、これを実装する方法がある場合、それらのアクティブなマッピングが後でどうなるかを知ることは興味深いでしょう。たとえば、それらを「null」に設定できますか（または設定されますか）？

この問題に関するあらゆる意見に感謝します。

テーブルAへの外部キーを持つテーブルBがあり、Aで「DELETECASCADE」を実行したいのですが、PostgreSQLは以下を受け入れません。

SELECTのみがIN ()句の中に入ることができるようです。これを行う簡単な（そしてPostgreSQL固有ではない標準SQL？）方法があると思いますか？

編集：あなたがこの種の問題にぶつかったとき、何かがひどく構造化されていると言っても安全ですか？私たちの場合、ヒットは..[expr]..ATableのサブセットとしてではなく、新しいCTAbleにあるべきだと直感していますが、それをサポートする設計パラダイムを実際に示すことはできません。

休止状態 3 を使用していて、データベース内のレコードを削除しようとしていますが、期待どおりに削除が機能しません。スキーマ休止状態は（疑似コードで）に対して機能しています：

私の休止状態のクラス マッピングは次のようになります。

今、この構成で私は呼び出しています:

発生しているのは次のとおりです。

そして例外が発生しています。session.remove(..) 呼び出しの結果として期待しているのは、削除される雇用者レコード、雇用者に関連付けられたすべての従業員レコード、および削除された従業員レコードに関連付けられたすべての EmployeeRole レコードです。これは正しい仮定ですか？それとも、ここで重要な概念を誤解していますか?

これが私が問題を抱えている3つのテーブルです：

• 表：機会-さまざまな機会（職務）の説明を保持します

• 表：Opportunities_Applicants-機会を申請するさまざまな申請者を保持します。1人の応募者は1つの機会にしか応募できませんが、1つの機会には多くの応募者がいる可能性があります

• テーブル：Opportunities_Category-カテゴリ名とタイプを保持します。1カテゴリは多くの機会に関連する可能性があります。

オポチュニティカテゴリが削除されたときにカスケード削除を実行しようとしています。これにより、対応するオポチュニティとそれらのオポチュニティの申請者が削除されます。

この構造は適切ですか、それともデータベースを別の方法で設定する必要がありますか？オポチュニティカテゴリが削除されたときにCASCADINGDeleteが機能するようにするには、テーブルの関係をどのように設定する必要がありますか？

CASCADING Deleteを使用する必要がありますか？

AとBの2つのエンティティがあるとします。Bは次のようにAと多対1の関係にあります。

ここで、Aオブジェクトを削除し、その削除をすべての子にカスケードしますB。これを行うには2つの方法があります。

1. cascade=CascadeType.ALL, orphanRemoval=trueOneToManyアノテーションに追加し、データベースからAオブジェクトを削除する前にJPAがすべての子を削除できるようにします。

2. クラスはそのままにして、データベースに削除をカスケードさせます。

後者のオプションの使用に問題はありますか？エンティティマネージャは、すでに削除されたオブジェクトへの参照を保持しますか？オプション2を選択する理由は、オプション1が削除のためにn + 1個のSQLクエリを生成するためです。これは、オブジェクトAに多数の子が含まれている場合に長時間かかる可能性がありますが、オプション2は単一のSQLクエリのみを生成してから次に進みます。幸せに。これに関する「ベストプラクティス」はありますか？

次のシナリオを考えます。

つまり、オブジェクトAとオブジェクトCの両方に多数のBオブジェクトが含まれています。

Cオブジェクトを削除するとき（技術的には、複数のCオブジェクトを含むオブジェクトを更新し、orphanremovalを使用しています）、現在のアノテーションで期待どおりに機能する、参照されているすべてのBオブジェクトを削除したいと思います。ただし、エンティティマネージャは、キャッシュ内にあるオブジェクトAが一部の子を失ったことを理解していないようです。Aのインスタンスがある場合は、もちろんそのbListを手動で更新するか、新しいクエリを実行して更新する必要がありますが、新しくフェッチされたAオブジェクトでさえまだ古くなっています。繰り返しますが：

• Cオブジェクトが削除されます。
• 削除は、orphanRemovalを使用してBオブジェクトにカスケードされます。
• エンティティマネージャにキャッシュされているオブジェクトのbListは更新されません。
• エンティティマネージャのキャッシュを手動で削除すると、適切に更新されたオブジェクトが取得されます。

これはどのように解決できますか？エンティティマネージャーが永続コンテキストを自動的に更新するか、@ JoinColumnでカスケードアノテーションを利用できるようにすることを期待しますが、ここではどちらも当てはまらないようです。

編集：問題は、オブジェクトAのbListが更新されたときにオブジェクトCのbListが更新されないことにあるようです（したがって、変更をカスケードできません）。理由はわかりませんが、インスタンス化されたオブジェクトではなく、永続コンテキストについて話していることに注意してください。

データベースに 3 つのテーブルがあります。

1. プロジェクト (ID、名前)
2. タグ(id、名前)
3. ProjectsTagss (id、projectId、tagid)

ご覧のとおり、ProjectsTags テーブルはブリッジ テーブルです。

これが私の流暢なnhibernateマッピングです

ProjectMap.cs:

ProjectsTagsMap.cs:

TagMap.cs:

ご覧のとおり、これまでタグ テーブルを他のものにリンクしていませんでした。タグとそのタグが使用される頻度を示すレポートを生成する必要があるため、タグから ProjectsTag に結合する必要があります。この行をタグマップに追加してみました:

しかし、タグ オブジェクトの名前を更新してコミットすると、次のエラーが発生します。

cascade="all-delete-orphan" を持つコレクションは、所有エンティティ インスタンスによって参照されなくなりました

タグテーブルを更新するだけで、この nhibernate 例外を引き起こす可能性のある、追加したものに問題があることを誰かが見ることができますか? 繰り返しますが、私の目標は次のようなことができるようにすることです:

要求された追加のコードを次に示します。

私のタグクラス: