Удаление m-to-m также пытается каскадно удалить один-2-один - PullRequest
Новая
       6

Удаление m-to-m также пытается каскадно удалить один-2-один

0 голосов
/ 09 октября 2010

У меня есть следующие домены 

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

Проблема в том, что когда я пытаюсь сделать board.removeFromCommittees (комитет), я получаю следующее исключение:

удаленный объект будет повторно сохранен каскадом (удалить удаленный объект из ассоциаций): [com.wbr.highbar.User # 1];

Я понимаю, что это значит. Чего я не понимаю, так это почему я это понимаю. Другим интересным моментом является то, что если я сделаю CreatDBy и ModifiedBy в экземпляре комитета нулевым, удаление работает просто отлично. Вот почему я думаю, что GORM пытается каскадировать один-два-один. Моя теория заключается в том, что это как-то связано с тем фактом, что пользователь принадлежит Комитету. Но я не знаю, как решить проблему.

1 Ответ

0 голосов
/ 10 октября 2010

Каскадное удаление происходит из-за отношений belongsTo между классами вашего домена.

Начиная с Committee belongsTo Board, когда Правление удаляется, удаление каскадируется в Комитет.Начиная с User belongsTo Committee, когда Комитет удаляется, удаление распространяется на Пользователя.

Решение вашей проблемы состоит в удалении отношения User belongsTo Committee.

Примечания к вашемуМодель предметной области в целом:

У вас много отношений «многие ко многим».Они не обязательно ошибаются, но могут усложнять ситуацию.Вы могли бы, вероятно, сойти с рук, просто используя: 

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