A continuación voy a hacer un pequeño resumen de las asociaciones más típicas que podemos hacer en GRAILS mediante GORM.
1.- Asociaciones Unidireccionales
1.1.- Muchos a uno (m:1) sin relación de pertenencia
class Face {
Nose nose
}
class Nose {
}
En este caso la foreign key va en la tabla padre referenciando a la tabla hija.
insert into nose (id, version) values (null, ?)
insert into face (id, version, nose_id) values (null, ?, ?)
Aunque parezca que la relación es uno a uno (1:1), realmente es muchos a uno ya que una instancia Face sólo puede referenciar a una instancia Nose sin embargo una instancia Nose puede estar referenciada por muchas instancias Face distintas ya que no se está indicando ninguna restricción en este sentido.
Como la tabla hija no pertenece a la padre, es decir no se ha especificado belogsTo, los saves y deletes no se propagarán desde la tabla padre a la hija.
Es decir,
def face = new Face(nose:new Nose())
face.save()
generará una excepción porque al no propagarse los saves la instancia Nose no se persitirá no pudiéndose persistir por tanto la instancia de Face al referenciar a un Nose que no existe a nivel de base de datos (transient).
En este caso es necesario hacer
def nose = new Nose()
nose.save()
def face = new Face(nose:nose)
face.save()
Al invocar a nose.save(), estamos diciendo que la instancia, que en ese momento es de tipo transient, pase a ser persistent y gestionada por la sesión. Esto no quiere decir que en ese momento se grabe realmente en base de datos.
Hibernate grabará en base de datos los objetos de la sesión en base a unas reglas, por ejemplo siempre que termine de generarse una vista. Si necesitamos que en un preciso momento, un save se refleje en base de datos deberemos hacer obj.save(flush:true)
Por la misma razón, el borrado de una instancia Face no borrará su Nose asociada.
Sin embargo sí que se podrá actualizar una instancia Nose desde una Face que la referencie. Por ejemplo:
def face = Face.get(1)
face.nose.cualquierPropiedad=valor
face.save()
En este caso, aún no especificandose belongsTo en la clase Nose, los cambios hechos se persistirán en base de datos. El motivo es que al invocar a
face.nose.cualquierPropiedad=valor
se lee la instancia Nose de base de datos (queda en estado persistent) y se actualiza en memoria por lo que cuando se persiste la sesión, se guardan los cambios de Nose en base de datos.
1.2.- Muchos a uno (m:1) con relación de pertenencia
class Face {
Nose nose
}
class Nose {
static belongsTo = Face
}
En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.
insert into nose (id, version) values (null, ?)
insert into face (id, version, nose_id) values (null, ?, ?)
Mediante la clausula belongsTo estamos especificando que una instancia de Nose pertenece a una instancia de Face. Las implicaciones son que los saves y deletes son propagados desde el padre al hijo. Es decir, podemos crear una instancia Face con una Nose transient:
def face = new Face(nose:new Nose())
face.save()
De igual forma, un delete sobre una instancia de Face borrará también la instancia Nose a la que referencia.
1.3.- Uno a uno (1:1) sin relación de pertenencia
Para modelar una relación muchos a uno (m:1) simplemente deberemos tomar una relación muchos a uno (m:1) y hacer que la referencia de la parte muchos sea única:
class Face {
Nose nose
static constraints = { nose unique: true }
}
class Nose {
}
En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.
insert into nose (id, version) values (null, ?)
insert into face (id, version, nose_id) values (null, ?, ?)
Ahora una instancia Face sólo puede referenciar a una instancia Nose y una instancia Nose sólo puede estar en una Face al declararse unique.
Esta forma tan rara y poco intuitiva de modelar relaciones 1:1 viene heredada de Hibernate.
Al no especificarse relación de pertenencia con belongsTo los saves y deletes no son propagados desde la instancia padre a la hija.
1.4.- Uno a uno (1:1) con relación de pertenencia
class Face {
Nose nose
static constraints = { nose unique: true }
}
class Nose {
static belongsTo = Face
}
En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.
insert into nose (id, version) values (null, ?)
insert into face (id, version, nose_id) values (null, ?, ?)
En este caso al especificarse relación de pertenencia con belongsTo los saves y deletes son propagados desde la instancia padre a la hija.
1.5.- Uno a muchos (1:m) sin relación de pertenencia
class Author {
static hasMany = [ books : Book ]
}
class Book {
String title
}
En este caso, a nivel de base de datos esta relación se modela mediante una tabla auxiliar (join)
Siempre, en las relaciones uno a muchos (1:m) por defecto se propagan los saves desde la clase padre a la hija aunque no se haya especificado relación de pertenencia con belongsTo. En este caso, como no se ha especificado una relación de pertenencia (belongsTo) si borramos la clase padre no se borrará la hija referenciada.
En las relaciones uno a muchos, lo más normal es añadir instancias en la clase padre mediante el método dinámico addTo.
Por ejemplo:
aAuthor.addToBooks(title:"Mi Libro")
aAuthor.save()
Debemos tener cuidado en este caso ya que a nivel de base de datos, no se persistiría inmediatamente la lista de los libros de un autor aunque invoquemos a save. En este caso si leemos de base de datos justo despues de hacer el save no obtendremos ningún registro:
println Book.list()*.title
El motivo es que Hibernate decide que en ese momento no es necesario persistir a base de datos posponiendolo para más adelante. Para hacer que en ese momento los datos queden registrados en base de datos es necesario invocar a save con flush:true
Sin embargo, en las relaciones 1:1 y m:1 que hemos visto una vez que hacemos:
def author = new Author(new Book())
author.save
las instancias Book y Author son creadas en base de datos por lo que una query a base de datos devolverían estos nuevos registros.
La razón es que en la relación 1:m, una instancia de la clase padre (Author) puede referenciar a cero o N libros (Book) mientras que en la relación 1:1 o m:1 una instancia de la clase padre tiene que referenciar necesariamente a un libro ya que la foreign key está en la tabla padre. Por lo tanto, en el primer caso Hibernate puede posponer la inserción en base de datos para más tarde mientras que en el segundo caso la inserción debe realizarse en el momento.
2.- Asociaciones Bidireccionales
2.1.- Uno a uno (1:1) con FK desde padre a hijo
class Face {
Nose nose
}
class Nose {
static belongsTo = [face:Face]
}
En este caso la foreign key va en la tabla padre referenciando a la tabla hija.
insert into nose (id, version) values (null, ?)
insert into face (id, version, nose_id) values (null, ?, ?)
Resaltar que la clausula belongsTo es distinta a la de las asociaciones unidireccionales, en este caso en la clase Nose se indica una propiedad face de tipo Face (face:Face) que es la referencia hacia atrás entre Nose y Face.
Al especificarse una relación de pertenencia, los saves y deletes son propagados desde el padre al hijo.
2.2.- Uno a uno (1:1) con FK desde hijo a padre
class Face {
Nose nose
static hasOne = [nose:Nose]
}
class Nose {
Face face
}
Este caso es idéntico al anterior salvo que la foreign key va en la tabla hija referenciando a la tabla padre.
insert into face (id, version) values (null, ?)
insert into nose (id, version, face_id) values (null, ?, ?)
Resaltar que no tiene sentido definir hasOne en la clase padre y belongsTo en la clase hija ya que estaríamos indicando cómo almacenar la FK de forma contradictoria.
2.3.- Uno a muchos (1:m)
class Author {
static hasMany = [ books : Book ]
}
class Book {
static belongsTo = [author:Author]
}
Este caso es idéntico a la relación unidireccional 1:m salvo que la hemos hecho bidireccional creando una asociación entre Book y Author mediante una clausula de pertencia belongsTo a través de la propiedad author de la clase Book.
Ahora, al haberse especificado una relación de pertenencia, si borramos la clase padre se borrará también la clase hija referenciada.
A nivel de base de datos esta relación se modela mediante una tabla auxiliar (join)
Imaginemos que tenemos una asociación bidireccional entre dos entidades y que en la clase hija existen dos propiedades del tipo de la clase padre:
// Esto no funciona
class Airport {
static hasMany = [flights:Flight]
}
class Flight {
Airport departureAirport
Airport destinationAirport
}
Este ejemplo no funcionaría porque no se sabe cuál de las dos propiedades de Flight: departureAirport o destinationAirport correspondería a la referencia inversa entre Airport y Flight. Es decir, desde un Airport conocemos todos los vuelos mediante la relación hasMany llamada flights, sin embargo desde un vuelo (instancia Flight) no sabríamos a qué aeropuerto pertenece ya que existen dos propiedades que apuntan a Airport.
Para solventar esto es necesario mapear en la clase padre la propiedad de la hija que va a corresponderse con la referencia inversa.
class Airport {
static hasMany = [flights:Flight]
static mappedBy = [flights:"departureAirport"]
}
class Flight {
Airport departureAirport
Airport destinationAirport
}
Ahora una instancia de Airport tienen muchos vuelos (flights), y desde un vuelo podemos conocer desde qué aeropuero salió mediante la propiedad departureAirport.
2.4.- Muchos a muchos (m:m)
class Book {
static belongsTo = Author
static hasMany = [authors:Author]
}
class Author {
static hasMany = [books:Book]
}
Las relaciones muchos a muchos (m:m) se modelan a nivel de base de datos mediante una tabla join.
Esta tabla join no puede ser modelada para añadir propiedades de la relación entre la clase padre y la hija que podamos necesitar.
Por esta razón, a veces cuando pensamos en relaciones muchos a muchos, es más conveniente pensar en dos relaciones uno a muchos apuntando la parte de los muchos a una nueva entidad donde podremos almacenar información extra aunque este consejo quizás no aplique a nuestra relación entre Author y Book ya que es demasiado simple.
