0

現在、Grailsで一方向の関係を作成するのに問題があります。

属性アドレスを持つクラストイレがあります。このアドレスは別のクラスです。アドレスが関連付けられているトイレオブジェクトが削除された場合、アドレスは（理論的には）まだ存在している可能性があります。住所を削除してもトイレも残ります。

GORMのhasOneは、双方向の関係を作成するため、私が必要とするものではありません。

タイプクラスの属性を定義すると、（それ自体のテーブルにもかかわらず）永続化されないアドレスのみが生成されます。つまり、アドレスとトイレオブジェクトの関連付けは存在しません。

私はこの種の関係にあまり精通していないので、私の目標を達成するための解決策または別の方法を本当に感謝します

私の問題が明確であることを願っています-コメントではない場合、私はさらに説明を追加しようとします

4

4 に答える 4

1

から取られた

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

5.3.3カスケード更新と削除について理解する

GORMを使用する場合、カスケード更新と削除がどのように機能するかを理解することが重要です。覚えておくべき重要な部分は、関係を「所有する」クラスを制御するbelongsTo設定です。これが1対1、1対多、または多対多のいずれであるかにかかわらず、belongsToを定義すると、更新と削除は、所有するクラスからその所有物（関係の反対側）にカスケードされます。

BelongsToを定義しない場合、カスケードは発生せず、各オブジェクトを手動で保存する必要があります。

したがって、belongsToを使用しない場合は、各オブジェクトを手動で保存すれば問題は発生しません。

于 2012-04-16T22:38:26.457 に答える
0

トイレの住所がhasOneまたはbelongsToマッピングのない単純な関連付けである場合、操作はカスケードされません。

つまり、住所を保存して割り当てtoilet.address、トイレを保存する必要があります。

于 2012-04-16T21:57:29.557 に答える
0

解決策を見つけました。

私が省略したのは、トイレクラスのインターフェイスの実装でした。

問題は（念のため）トイレクラス内の住所の関係がデータベースに保存されていないことでした。

これはインターフェース自体の問題でした。このインターフェースでは、ゲッターとセッターが定義され、実装する必要がありました（インターフェースの動作方法-明らかに）。ここでの問題は、Address-AttributeのセッターがTypeを予期していたことIAddressです。

セッターをオーバーロードして、タイプのパラメーターも受け取りましたAddress。

この変更により、との間の関係がToiletデータベースAddressに正しく保存されます。アドレスのIDがトイレのテーブルに保存されます。

セッターの定義は単なる間違いだと思います（私はインターフェースに影響を与えません）が、この回避策で私はそれをとにかく動作させることができます

この説明が他の人にも役立つことを願っています。

于 2012-04-17T20:20:00.547 に答える
0

関連付けをモデル化するクラスを用意してみませんか？

class ToiletAddress {
  Toilet toilet
  Address address
  ...
}

...次に、ロジックをサービスにラップして、トイレにアドレスを割り当て、トイレまたはアドレスを削除します。

制約を使用して、それがどのような種類の関連付けであるかを定義できます。例：1-1、1-n（両側）、およびnm

static constraints = {
  address unique: ['toilet']
  toilet validator: {val, obj -> ... }
}
于 2014-10-07T18:20:36.427 に答える