Tengo que mirar más en detalle JPA (Java Persistence Api), pero si los propios miembros de la especificación lo suponen un subconjunto de JDO (Java Data Object), es de suponer que sea parecido. De todos es conocido el problema de Hibernate (y cualquier ORM) con lazy loading, de hecho ya hemos hablado aquí sobre ello. Básicamente sucede cuando después de cerrar el la transacción en el controlador (una acción de struts por ejemplo, o una clase de servicio) queremos cargar objetos relacionados definidos como lazy en la vista. Ahí aparece el temido LazyInitializationException.
Hoy no voy a hablar de eso, ya hay soluciones como el OpenSessionInView (he olvidado el término patrón a propósito), o más inteligentes, como utilizar Spring, por mucho que a alguno le pese. Pero en lugar de eso, voy a hablar de un desconocido, y como lo resuelve él: JDO, por si alguien tiene que escoger un ORM y se niega al borreguismo (dicho esto sin acritud hacía Hibernate, sino simplemente quiere ver distintas opciones, que nunca es malo).
En JDO, al igual que la mayoría de los ORM, tenemos por una parte nuestros beans, por otra la base de datos, y en medio tenemos un fichero con metainformación que relaciona ambas cosas, normalmente un xml. Sin entrar en detalles de como se trabaja con JDO, casi todos podrán entender:
Esta es la definición de una clase Task, que tiene varias relaciones (los campos primitivos no hace falta definirlos si nos valen los valores por defecto). La parte interesante es la del final, la llamada fetch-group.
Y es que por defecto se cargan las relaciones de forma perezosa, como en casi todas partes (y por tanto tendríamos el mismo problema). En JDO podemos definir distintos fetch-groups, para distintos usos normales de la clase, definiendo que queremos que se cargue en esos casos. Por ejemplo, en este caso, cuando cargamos un grupo de Task para un listado, se cargará el grupo por defecto (primitivos + String + Date, pero no relaciones, salvo status porque así lo hemos definido), pero cuando queremos mostrar una página de detalle, nos interesa tener a mano información sobre el tipo de tarea que es (taskType), su estado (en este caso es un objeto, no un valor, status), o si tiene añadidos varios fallos (bugs). Dejamos sin cargar los partes de horas, historial de cambios, etc.
Simplemente a la hora de hacer la consulta haremos algo así como (escribo de memoria):
query.getFetchPlan().addFetchGroup("detailsPage");
Limpíto, ¿no?.
Share This
Ultimos comentarios
Goio Telletxea, Xavi, Diego
» Fin del Linking Internship ¿Qué pasa con flatee?
Decepción con el Linking Internship 2008 at Linked, FIXME: Empezar muchas cosas, terminar algunas menos. at Linked, » Flatee.com o cómo crear un proyecto en internet, ¿Buscas un piso compartido? at Linked, Empezamos con flatee at Compartido, » Trabajando con Linking Paths, ¿Qué queréis saber de Linking Paths? at Linked, alberto, Jose, aitor [...]
La innovación empieza por ser creativos en la gestión « Towards 2.0 Emprendiendo en época de cambios
Manuel, aitor, Manuel, » Tog, plataforma Open Source, aitor, Nacho
GreenEyed, aitor, GreenEyed