Dans une correspondance un-à-plusieurs ordinaire, le côté "un" est le propriétaire de l'association. Pourquoi quelqu'un utiliserait-il l'belongsTo-mapping pour une telle cartographie? Ai-je manqué un effet secondaire en spécifiant belongsTo? En d'autres termes: quels sont les effets de la spécification d'un appartenance-mapping dans GORM par opposition à ne pas le spécifier?Grails/GORM: La signification de belongsTo dans les relations 1: N
Le fait de spécifier belongsTo dépend du type de referential action souhaité.
Si vous voulez faire Grails sur Supprimer, CASCADE action référentielle, ne spécifiez belongsTo. Si vous voulez que Grails fasse En cas de suppression, action référentielle RESTRICT, NE PAS spécifier belongsTo.
par exemple.
// "belongsTo" makes sense for me here.
class Country {
String name
static hasMany = [states:State]
}
class State {
String name;
// I want all states to be deleted when a country is deleted.
static belongsTo = Country
}
// Another example, belongsTo doesn't make sense here
class Team {
String name
static hasMany = [players:Player]
}
class Player {
String name
// I want that a team should not be allowed to be deleted if it has any players, so no "belongsTo" here.
}
Espérons que cela aide.
Spécifier belongsTo permet à Grails de mettre en cascade de façon transparente les mises à jour, les sauvegarder et les supprimer des enfants de l'objet. Sans belongsTo, si vous tentez de supprimer une fiche, vous obtiendrez une violation de clé étrangère si elle possède des détails.
puis-je vous poser une question à propos de belongsTo? Et si je disais au joueur appartient à l'équipe mais je n'ai pas dit que l'équipe a de nombreux joueurs. Si l'équipe a été supprimée, que se passe-t-il avec Player, seront-ils également supprimés? – nightingale2k1
@ nightingale2k1 - Je pense que si vous avez mappé Team-Player de cette façon, il n'y aura aucune association entre les deux, donc un joueur lorsque l'équipe correspondante est supprimée –
très bien expliqué, merci – add9