Grails - カスケード削除を伴う同じクラスの複数のbelongsTo

Question

これはGrailsユーザのためのものです。私はgrails - userメーリングリストでそれを尋ねましたが、私は数日間これを戦っていたので、私はできるだけ広いネットにキャストすべきだと考えました。

2つのオブジェクトを参照する別のオブジェクト（異なるタイプ）の同じタイプの2つの オブジェクト間の関係をモデル化しようとするといくつかの問題があります。

私がしようとしていることの例として、 あなたは家族の間の関係をモデリングしているとします。任意の与えられた関係 "belongsTo" 2つの異なる家族。だから、：

class Person { 
    hasMany[relationships: Relationship] 

    static mappedBy = [relationships:'p1', relationships:'p2'] 
} 

class Relationship { 

    Person p1 
    Person p2 
    String natureOfRelationship // for example, "cousins" 

    static belongsTo = [p1: Person, p2: Person] 
} 

ここでの意図は、hasManyのマップ内のすべてのリレーションシップのオブジェクトに削除します カスケード、その後、いずれかのP1またはP2が削除された場合ということです。代わりに、私はそれを試すたびに 、私は外国キー違反で終わる。ドキュメントに記載されて、私は 「カスケード」属性を使用してみました：

http://grails.org/doc/1.0.x/guide/single.html#5.5.2.9%20Custom%20Cascade%20Behaviour

をだから私は、私はPersonクラスにこれを追加します考え出し：

static mapping = { 
    relationships cascade:'delete' 
} 

私は運を持っていませんでしたどちらかと一緒に。

また、Grailsが生成するdevDB.scriptファイルを見て、 がリレーションシップで外部キーを設定していたことを確認しました。両方の外部キー制約に手動で "ON DELETE CASCADE"を追加すると正常に動作しますが、 自動的に生成されたデータベーススクリプト を手動で編集するのは明らかです。理想的には、GORMを使用してその動作を と指定できるようにしたいと思います。

ここで私の最高の賭けは何ですか？ 複数の外部キー/所有者のカスケード削除を強制する方法はありますか？ PersonのonDeleteアクション で手動で行う必要はありますか？ のためにHibernateの設定を取得する必要がありますか、Grails/GORMで何らかの方法で行うことはできますか？

お時間をおかげで何か助けてもらえますか？

Answer 1

フックをPersonクラスに追加して、他の親を照会することができます。他の親が存在しない場合、その関係を削除することができます。関係には両方のFKがあるので、おそらく両親を削除する必要があるため、外部キー違反に遭っていることに注意してください。

Answer 2

また

incomingRelationsとoutgoingRelationsは（該当する場合、ドメインへの）区別するために使用可能な単語を思える人

で2 Relationshipcollectionsを定義することができます。

あなたは

class Person { 
    Relationship incomingRelations 
    Relationship outgoingRelations 
    static mappedBy = [incomingRelations:'p1', outgoingRelations:'p2'] 

    static transients = ['relations'] 

    Set getRelations() { 
     //creates a new collection as union of the old ones 
     return Collections.unmodifiableSet(this.incomingRelations + this.outgoingRelations) 
    } 
} 
class Relationship { 
    static belongsTo = [p1:Person, p2:Person] 
} 

（それを修正しないようにしてくださいする/それらの変更は、最も可能性の高い意味をなさないだろう不変）の両方relationshipcollectionsの和集合を返すだけゲッターと過渡特性の関係を定義することができもし私が合わないなら、私はMiguel-Pingが提案する均等なアプローチを試みるでしょう