Deleting m-to-m is also trying to cascade delete a one-2-one

Question

I have the following Domains

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
    ]
}

The problem is that when I attempt to do a board.removeFromCommittees(committee) I'm getting the following exception:

deleted object would be re-saved by cascade (remove deleted object from associations): [com.wbr.highbar.User#1];

I understand what that means. What I don't understand is why I am getting it. The other interesting bit is that if I make creatdBy and modifiedBy in the Committee instance null, the delete works just fine. That's why I am thinking that GORM is trying cascade the one-2-one. My theory is that is has something to do with the fact User belongsTo a Committee. But I don't know how to fix the problem.

Answer 1

The cascading delete is effected by the belongsTo relationships between your domain classes.

Since Committee belongsTo Board, when a Board gets deleted, the delete cascades to the Committee. Since User belongsTo Committee, when a Committee gets deleted, the delete cascades to the User.

The solution to your problem is to remove the User belongsTo Committee relationship.

Notes on your domain model as a whole:

You have a lot of many-to-many relationships. They're not necessarily wrong, but they might be overcomplicating things. You could probably get away with just using:

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
}