Grailsから親を削除している間に子を削除しないようにする方法は？

Question

私はこの

Author.groovy

class Author { 

    String authorName; 
    String authorAddress; 
    String authorCNIC; 

    static hasMany = [books:Book] 

    static constraints = { 

     books(nullable: true) 
    } 
} 

ように私は、ドメインクラスを持っている

... 1人の著者が多くの本を持って、作者と本の間には多くの関係に1を持っているBook.groovy

class Book { 

    String bookName; 
    String Isbn; 

    static belongsTo = [author:Author] 

    static constraints = { 

     author(nullable: true) 
    } 



} 

この関数を呼び出すとき

def deleteauthor() 
    { 
     def id=params.id 
     Author author = Author.findById(id); 
     author.delete(flush: true) 
     render "Author Deleted" 
    } 

それは著者とそのすべての子ブックを削除します。私はこの動作をしたくない、私はそれが著者と書籍を削除することはできませんし、メッセージを表示することはできませんこれを行う ？

Answer 1

あなたが制約にcascade: 'none'を追加する必要があり、あなたの著者モデルで：

class Author { 

    String authorName; 
    String authorAddress; 
    String authorCNIC; 

    static hasMany = [books:Book] 

    static mapping = { 
     cascade: 'none' 
    } 
} 

これは削除本を防止するであろうし、ちょうどnullにauthor_idを設定します。

UPDATE：

cascade 'none'を設定することもカスケーディングセーブを無効だろうと思われます。 追加されたブックインスタンスごとに手動でsaveを呼び出すこともできます。

私は考え出し他の事：

あなたはsave-update上だけの作業にカスケードを設定することができますが、著者が削除されたときに休止状態にon delete set nullを設定する方法がないため、その後、制約違反の例外があります。 beforeDeleteで手動で行うことができます。

class Author { 

    String name; 

    static hasMany = [books:Book] 

    static mapping = { 
     books cascade: 'save-update' 
    } 

    def beforeDelete() { 
     Book.withNewSession { 
      Book.findAllByAuthor(this).each { 
       it.author = null 
       it.save(flush: true) 
      } 
     } 
    } 
} 

非常にきれいではありませんが、動作しているようです。

Answer 2

私の評判のため、私はコメントを残すことはできませんが、私は答えることができます。作成者を削除するときにその書籍を削除する理由は、作成者ドメインで「belongsTo」が設定されているためです。これは関係を誰が所有しているのか、カスケーディングがどのように処理されるかを指示します。あなたは以下を参照してくださいすることができます

：

• http://docs.grails.org/2.5.4/guide/GORM.html#cascades
• http://spring.io/blog/2010/07/02/gorm-gotchas-part-2/

具体的に：他のrelatioと同様に

カスケード

コレクションをマスターすることは、カスケード動作をマスターすることを意味します。最初に注意しなければならないのは、belongsToが指定されていなくても、セーブは常に親から子にカスケードされるということです。それが当てはまる場合、belongsToを使用することは何ですか？はい。

は、我々は、著者と彼の本を追加した後、我々は、コンソールでこのコードを実行するとどうなるか考えてみましょう：言い換えれば

class Book { 
    String title 

    static constraints = { 
    title(blank: false) 
    } 

} 

class Author { 
    String name 
    Location location 

    static hasMany = [ books: Book ] 
} 

def a = Author.get(1) 
a.delete(flush: true) 

println Author.list()*.name 
println Book.list()*.title 
The output looks like this: 


[] 
[Empire, Colossus] 

を、著者は削除されているが、本は持っていません。それはbelongsToが入るところです：削除がカスケードされ、保存されることを確実にします。静的belongsTo = AuthorをBookに追加するだけで、上記のコードはAuthorとBookの空のリストを出力します。シンプル、そう？この場合、はい、本当の楽しみはほんの始まりです。

AuthorToを削除するとカスケード削除は停止されますが、Booksはそのままになります。私は、関連するエンティティがあるのに削除のエラーを引き起こす方法があると思うが、現在どのように覚えていない。これは少なくとも、カスケードの削除に対してあなたを守るでしょう。

「著者著者」を追加して、まだ関係を保つことができると思います。