問題タブ [all-delete-orphan]

Grailsでは、子クラスを持つことができます。

2つの親クラスを使用

Ifather.delete()の場合、GrailsはデータベースエラーをスローしてFather、がまだ存在しているため削除できないことを示しchildているようです。

クラスにクラスへの直接参照がない場合、どうすればall-delete-orphanカスケードできますか？ChildFatherChild

hibernate と delete-orphan カスケードに関する質問。その中に子のコレクションを持つ親クラスがあるとします。一対多関係の親クラスの休止状態のマッピングで、カスケード all-delete-orphan を設定しました。残りはすべて正しく構成されているとします。

そこで、親 P に 2 つの子オブジェクト A と B を読み込みます。次に、子 A を親コレクションから削除し (.getChildren().remove(A))、session.saveOrUpdate(P) を呼び出して親オブジェクトを保存します。all-delete-orphan カスケードが設定されているため、親オブジェクトは 1 つの子と共に保存され、別の削除された子 (A) が DB から削除されます。それは正しい行動です。

私が理解しているように、休止状態がそのようなオブジェクト (P) をロードすると、その子リストがいくつかの永続コレクション (PersistentSet など) にラップされ、このコレクションのすべての操作は休止状態によってインターセプトされ、これにより、どの子を db から孤立して削除するかを決定できます。

しかし..私は次のプロジェクトアーキテクチャを持っています:

エンティティが db (DO オブジェクト) からローダーになった後、サービス (ファサード オブジェクト) に渡され、Dozer フレームワークを使用して TO オブジェクトに変換されます。変換後、DO オブジェクトからの永続的なコレクションは、TO の単純な ArrayList に変換されます。次に、変更可能な UI に渡されます (子コレクションから子 A を削除します)。それを保存したいときは、それをfacadeに渡し、Doserを使用してDOオブジェクトに変換し直してから、DBに保存します(session.saveOrUpdateを使用)。

この場合、カスケードは機能せず、削除された子は孤立しません。それはまだdbに表示されています。

カスケードは、saveOrUpdate の代わりに .merge を呼び出した場合にのみ機能します。休止状態が自動的にオブジェクトをセッションにバインドし、それを更新するためだと思います。

それで、誰かが私にこの行動を説明できますか？このような DO -> TO -> DO 変換を使用して、delete-orphan カスケードをサポートすることは可能ですか?

これは、よくあるシナリオとよくある質問です。必要に応じて、コード/マッピングなどを添付できます。

1対多の関連付けのデータバインディングを処理するGrailsの機能を利用しようとしています。リレーションシップに正常に割り当てることはできますが、単一の要素またはすべての要素を削除しても機能しません。

これが私のモデルがどのように見えるかの例です：

Webサイトを介して新しいScheduledCourierオブジェクトを作成する場合、次のようにマークアップで自動的にバインドするルートのリストを渡すことができます。

これは私のコントローラーでうまく機能します：

代わりに次のマークアップを使用すると、デバッガーをステップスルーして、routesプロパティが[]になり、オブジェクトは正常に保存されますが、レコードはデータベースから削除されないことがわかります。

さらに、次のようなマークアップを送信した場合：

courier.routesは、1つのオブジェクトのみを含むように更新されません。

誰かがこの行動を見たことがありますか？

これはGrails1.3.7です...少なくとも今のところは。

この動作を再現する統合テストを作成しました。

News と NewsComment の 2 つのエンティティがあります。

と

そして次のようなコード：

私は得る

News と CommentNews をまとめてカスケード削除したい

みたいな関係を持っています。

私のJavaコードでは、これに対して実行されるセットがありました

現在、この SomeBeans はlinkedHashmapであるため、順序は維持されましたが、カスケードで使用されているすべての孤立した削除のため、特定のシナリオで次のように例外が発生していました:

だから私は上記のJava実装を

ただし、これを行うと、linkedHashMap SomeBeans からの注文を維持できません。

誰かがそのような問題に直面したことはありますか?

よろしく、

バイバブ

ここでわずかな問題：

私は2つのエンティティクラスを持っているとしましょう

現在、マッピングは基本的に次のとおりです。

(ここでは ID マッピングとフィールドを省略しました。通常の生成 ID を使用します)

親のリストから要素を削除してから親をコミットするときのように、基本的にクリーンなデータベースを維持する必要があり、それに応じて削除された子データベースのエントリを削除する必要があります。子インスタンスは、後で削除できるようにする必要がある他のエンティティを参照するため、子インスタンスがデータベースに残っていると、参照されたオブジェクトを削除できません。

これまでにわかったこと: 休止状態の PersistentCollection ラッパーを所定の位置に保持する場合、以下で試したことはどれも機能するはずです。問題は、データベース オブジェクトがフレームワークのいくつかのレイヤーを通過することです。これには、Bean プロパティの抽象化を使用してセッターを呼び出す UI フレームワークと、オブジェクトのクローンを作成して前後にシリアル化するネットワーク通信レイヤーが含まれます。これらのレイヤーはどちらもコレクション インスタンスを内部的に置き換えるため、これらの PersistentCollection ラッパーを削除します。そうしないようにこれらを書き換えることはオプションではありません。

そうは言っても、私が試した8つのことはうまくいきませんでした：

1) リレーションを cascade="all" として構成し、session.update(parent) を使用します。

2) 関係を cascade="all-delete-orphan" として構成し、session.update(parent) を使用します。

3) リレーションを cascade="all" として構成し、session.merge(parent) を使用します

これらはすべて、「UPDATE CHILD SET parent.id = null WHERE parent.id = ...」を実行する休止状態になります。これは、親インスタンスをリロードするときに親リストから子を削除することに成功しますが、子インスタンスはデータベースに残り、参照されている他のエンティティを削除できません。

4-6) 構成 1-3 を使用し、さらに親キー列を非 null として定義する

これにより、休止状態は何もしなくなります。別の投稿で、キー列を非 null にすると削除されることを読みました。null への更新はオプションではなくなったため可能ですが、機能しません。コレクションから子を削除し、変更をコミットしてデータベースからインスタンスをリロードすると、子が再び表示されます。

7+8) 親キーが null 可能かどうかは問題ではありませんが、リレーションを cascade=all-delete-orphans として構成し、session.merge(parent) を使用します

これにより、PersistentCollection ラッパーが削除されたため、hibernate は例外「cascade="all-delete-orphan" を持つコレクションは、所有エンティティ インスタンスによって参照されなくなりました」をスローします。

私の問題を解決するために必要なのは、休止状態でオプション 1 ～ 3 のクエリを UPDATE ではなく DELETE として実行することだけです。PersistentCollection ラッパーなしでこれらを削除する方法でマッピングを構成するオプションが見つからないことを願っていますが、現在、そのようなオプションはないように見えます。これを設定する方法があるかどうか誰かが知っていますか?

/編集：明確にするために、私がしたいことの例：

ドアを持つ Car エンティティがあります。車が削除されたら、ドアも削除する必要があります。ドアだけでは意味がないからです。FluentNHibernate でのマッピングは次のとおりです。

CarDao 内の Delete メソッドは次のようになります。

ただし、この方法で車を削除すると、ドアは削除されませんが、carId は NULL に設定されます。私は、Cascade.AllDeleteOrphan() が子 (Doors) の削除を処理すると考えました。Delete メソッドを次のように作り直す必要がありました。

オブジェクトを削除する前にオブジェクトを取得する必要があるとは思えないため、ここで何かが欠けているように感じます。何かご意見は？

コレクションが「親」オブジェクトによってall-delete-orphanにマップされている場合、コレクションを更新する正しい簡単な方法は何でしょうか? 更新とは、コレクションに項目を追加/削除することだけではなく、項目のプロパティの値を更新することも意味します (もちろん、以前にコレクションにあった項目の場合)。

シナリオでは、Parentオブジェクトのコレクションを持つオブジェクトがあり、Childユーザーが Children コレクションを編集できるフォームが 1 つあります。子を追加/削除するだけでなく、子のプロパティを(同じフォームで) 編集することもできます。

基本的に私はこのようなものが欲しい：

これは機能せず、その理由は理解できますが、休止状態を使用して UI アプリケーションを開発する場合、これは非常に一般的な状況であるように思われるため、(本による) 解決策を探しています。

私は休止状態 3.6.10 と XML ベースの構成を使用しています。
関連するマッピングは次のとおりです (子コレクションの格納に ArrayList を使用しています)。

それが重要な場合、子オブジェクトにも同じ方法でコレクションがマップされていますが、それは説明されている問題と同じ問題であるため、関連性はないと思います。

ところで。私はこれで一日を失い、もちろんこれと非常によく似た質問を何十もチェックしましたが、これを解決するための合理的な解決策やパターンは見つかりませんでした. おそらく私は何かを逃していますか？

こんにちは、部門エンティティがあります。その部門エンティティには、文字列データ型で部門名と呼ばれるプロパティがあり、その列の外部キーとして部門データ型（クラスタイプ）として別のプロパティ親部門があります。そして、1対1の関係を使用しましたカスケード タイプは orphan-delete です。親部門を削除する場合、子部門を削除したくないため、ここでは orphan-delete を使用しましたが、次のように例外が発生します。 例外

部門エンティティ