問題タブ [cascading-deletes]

次の（簡略化された）Hibernateエンティティがあります：

そのため、1 つの「トップ」コンテンツを持つ 1 つのパッケージがあります。最上位のコンテンツは、カスケードが ALL に設定された状態でパッケージにリンクします。トップ コンテンツには多くの「サブ」コンテンツが含まれる場合があり、各サブコンテンツには独自のサブコンテンツが多数含まれる場合があります。各サブコンテンツには親パッケージがあり、これは最上位のコンテンツと同じパッケージである場合もそうでない場合もあります (つまり、コンテンツとパッケージの多対 1 の関係)。

関係は、ManyToOne (パッケージからコンテンツへ) および ManyToMany (コンテンツからサブコンテンツへ) である必要がありますが、現在テストしているケースでは、各サブコンテンツは 1 つのパッケージまたはコンテンツのみに関連しています。

問題は、パッケージを削除してセッションをフラッシュすると、 table の外部キー制約に違反していることを示す Hibernate エラーが発生subcontentsし、特定のcontent_idものが table からまだ参照されていることsubcontentsです。

パッケージを削除する前にコンテンツを具体的に (再帰的に) 削除しようとしましたが、同じエラーが発生します。

このエンティティ ツリーが適切に削除されない理由はありますか?

編集:回答/コメントを読んだ後、コンテンツには複数のパッケージを含めることはできず、サブコンテンツには複数の親コンテンツを含めることはできないことに気付きました。残念ながら、それで問題は解決しませんでした。

また、コンテンツから親パッケージに戻る双方向リンクも追加しましたが、これは簡略化されたコードには含まれていません。

カスケード削除と外部キー参照について質問があります。次のテーブルを想定してみましょう。

FKID_ITEMY にはカスケード削除があり、ITEMX の行を削除すると、ITEMY の対応するアイテムが削除されます。私の質問は：

ITEMX の行 ID 1 を削除すると、ITEMY の行 ID 1 も削除されますか?

それとも、行 ID 2 がまだ ITEMY の行 ID 1 を参照しているため、ITEMX の行 ID 1 を削除しますか?

つまり、ITEMY の行 ID 1 への参照がなくなったら削除されるようにしたいと考えています。カスケード削除はこれを達成しますか?

テーブル A に 2 つの子テーブル B と C があり、AB 間でカスケード削除を行い、AC 間でカスケード削除を行うとします。

A で行が削除されると、B と C の一致する行が削除されます。

SQL Server はカスケードを起動する順序をどのように決定しますか? ABカスケード削除が発生する前に、ACカスケード削除を起動する必要があります。

トリガーを使用してこれを実行できることはわかっていますが、絶対に必要でない限り、実行したくありません。

私は問題を調査しています.PとQの2つの「親」クラスがあり、「子」クラスCに全削除孤児をカスケードします.Hibernateでの私の直感は、これは本当に悪い考えであり、私はコードが P のインスタンスを削除するとき (つまり、 session.delete(myP); )、おそらくこれを確認するエラー メッセージを取得します。

「削除されたオブジェクトはカスケードによって再保存されます (関連付けから削除されたオブジェクトを削除します): [C#1]」

P のインスタンスと Q のインスタンスの両方が C の同じインスタンスの親として機能できる場合、単一の子クラスに対して 2 つの親クラスを持つことは悪い考えであることを誰かが確認できますか?

ありがとう！

私はPHPプロジェクトを継承しており、クライアントはCMSにいくつかの機能を追加したいと考えています。基本的に、CMSを使用するとニュースを作成でき、すべてのニュースは同じコンテンツで始まり、実際のニュースの見出しである1つのテーブルに保存されます。記事は別のテーブルに保存され、ニュースの画像は別のテーブルに保存されます。基本的に、ニュースのベース行が削除された場合、関連するすべての行を削除する必要があります。データベースは外部キーで機能するように設定されていません。カスケード削除を使用できないので、ベースニュース行のIDのみを使用している場合、必要なすべてのコンテンツを削除するにはどうすればよいですか？

どんな助けでも非常に役に立ちます申し訳ありませんが、これ以上の助けを与えることはできません。これが役立つ場合は、これがテーブルスキームの元のSQLですか？

スキーマを変更することも、外部キーを使用できるようにDBをMYISAMに変更することもできないことに注意してください。

エンティティ (ForumTopic) を削除し、その中の投稿 (ForumPost) を削除しようとしています。ここに私のエンティティがあります:

次のマッピングを使用します。

ただし、トピックを削除すると、次のエラーが表示されます。

[ForumTopic.Posts#14][SQL: UPDATE ForumPosts SET TopicID = null WHERE TopicID = @p0]

HasMany マッピングで Cascade.All() (イベントは Cascade.Delete() を試しました) と言って、このトピックのすべての投稿を削除すると思ったので、これは奇妙に思えます。誰かが私が間違っていることを教えてくれれば幸いです。ありがとう

LLBLGenで「カスケード削除」として最もよく説明されているように見えることを行う簡単な方法はありますか？私が探しているものの例：

あなたはこれらのテーブルを持っています：

ここで、特定の顧客とそれに依存するすべてのもの（すべての注文、およびすべての注文の注文の詳細）を削除したいと思います。IDを外部キーとして持つ注文を削除する前に顧客を削除すると、データベースは適合をスローするため、次のことを行う必要があります。

1. 顧客を獲得する
2. 顧客の注文を取得する
3. 各注文のOrderDetailsを取得します
4. 各OrderDetailを削除します
5. 各注文を削除する
6. 各顧客を削除する

さて、これはかなり一般的なタスクのようです-どこかにある種のDelete（Entity entityToDelete、bool isRecursive）関数があると思います。とにかく、これを行う簡単な方法はありますか？

素朴な質問かもしれませんが、削除と更新は常に連鎖的に行われるべきだと思います。しかし、それには問題があるのか​​、それをすべきでないのはいつなのかを知りたかったのです。カスケード削除を行いたくないケースは今のところ思いつきませんが、確かにあると思います...しかし、更新は常に行う必要がありますか?

削除と更新のカスケードの長所と短所を教えてください。ありがとう。

削除をカスケードしない 1 対多の関連付けを作成したいと考えています。Grails Referenceを読むと、

デフォルトのカスケード動作では、保存と更新がカスケードされますが、begsTo も指定されていない限り、削除はカスケードされません。

それは私が見ている動作ではありません。次のクラスの実装では、begsTo なしでカスケードされた更新、保存、および削除を取得します。

ある Hibernate セッションで、カスケード更新が機能することを確認するために次のことを行います。

次に、別の Hibernate セッションで、次のコードは AとBのすべてのインスタンスを削除します。

これはバグですか？ドキュメントは間違っていますか？私は何か間違ったことをしていますか？この動作を確認するために Grails コンソールを使用しています。

cascade="delete" がどのように機能するかについて、私は少し混乱しています。City マッピング ファイルで次のようにマッピングを定義しました。

クラス Client には、クラス City への外部キーがあります。

だから私が実行すると：

すべてのクライアントも削除する必要がありますか、それとも何らかの方法で処理する必要がありますか? クエリをメソッド パラメータとしてセッションの delete() メソッドに正しく渡していますか? 助けてくれてありがとう。よろしく、サス。