m à Suppression m essaie aussi de supprimer une cascade-2-one

Question

je les domaines suivants

class Committee { 
    String name 
    BoardCommitteeType boardCommitteeType 
    Date dateCreated 
    Date lastUpdated 
    User createdBy 
    User modifiedBy 

    static belongsTo = [ 
     board: Board, 
    ] 

    static hasMany = [   
     members: User 
    ] 
} 

class User { 

    static hasMany = [    
     committees: Committee,  
    ] 

    static belongsTo = [ 
     Board, Committee 
    ] 
} 

Le problème est que lorsque je tente de faire un board.removeFromCommittees (comité) I Obtient l'exception suivante:

objet supprimé serait ré-enregistré par cascade (supprimer l'objet supprimé des associations): [com.wbr.highbar.User # 1];

Je comprends ce que cela signifie. Ce que je ne comprends pas, c'est pourquoi je l'obtiens. L'autre bit intéressant est que si je crée creatdBy et modifiedBy dans l'instance de comité null, la suppression fonctionne correctement. C'est pourquoi je pense que GORM essaie de cascader le one-2-one. Ma théorie est que cela a quelque chose à voir avec le fait que l'utilisateur appartient à un comité. Mais je ne sais pas comment résoudre le problème.

Answer 1

La suppression en cascade est effectuée par les relations belongsTo entre vos classes de domaine.

Depuis Committee belongsTo Board, lorsqu'un tableau est supprimé, la suppression est répercutée au comité. Depuis User belongsTo Committee, lorsqu'un Comité est supprimé, la suppression cascade vers l'Utilisateur.

La solution à votre problème consiste à supprimer la relation User belongsTo Committee.

Notes sur votre modèle de domaine dans son ensemble:

Vous avez beaucoup de plusieurs à plusieurs. Ils ne sont pas nécessairement faux, mais ils peuvent compliquer les choses. Vous pourriez probablement partir avec juste en utilisant:

class Committee { 
    static hasMany = [boards: Board, users: User] 
} 

class Board { 
    static hasMany = [users: User] 
    static belongsTo = Committee // this is the only belongsTo you need, since if a 
           // committee is dissolved, presumably the board 
           // will be dissolved as well (unless you have 
           // cross-committee boards) 
} 

class User { 
    // doesn't define any relationships, 
    // let the Committee/Board domains handle everything 

    // also, this is presuming that users are at a higher level than committees, i.e. 
    // a user could belong to multiple committees 
}