Se hace camino al andar...

Bueno. Parece que hoy ha acabado la semana de Hibernate. Resulta que desde el pasado Jueves me he estado peleando con Hibernate por culpa de una dichosa excepción.

Resumiendoos un poco el problema. Tengo una tabla recursiva ( la típica de empleado que puede tener otros empleados a su cargo ) y dentro de esa tabla puede haber dos tipos de registros por lo que se presentaban las dos soluciones clásicas: una tabla para todo con un valor discriminador o una tabla por cada subclase.

Pues bien, resulta que la segunda alternativa no funciona. Claro, esto lo descubrí después de preguntar en los foros de hibernate y que me dijeran que no sabían de que podía ser y después de estar varios días creando un ejemplo muuuuy simplificado de mi programa para ir depurando poco a poco. Al final, la razón oficial es que HypersonicSQL no se comporta demasiado bien con la alternativa de una-tabla-por-subclase i.e. en Hibernate.

La solución propuesta desde los foros (después de decirles lo que había descubierto) fue actualizar a la última versión del CVS de Hibernate ( 2.0.1 ). Vale. Un día más para portar toda la aplicación ( y el test ) a Hibernate 2.0.1 desde Hibernate 1.2.5 para que al final .... no funcione. Además, puedo garantizar que la migración no es todo lo fácil que debería ser.

Solución: Una tabla para todas las subclases.

Bien. Este mensaje era para hacer algunas reflexiones sobre este tipo de herramientas O/R:

• Documentación: En general excasa, y eso que Hibernate es uno de los motores que más documentación tiene, pero aún así siempre aparece algún bug que no viene reseñado, al menos en alguna página de fácil acceso.
• Estandarización. Una de las ventajas de los Entity Beans o de JDO que no se suele resaltar mucho es la estandarización. Son especificaciones que están ahí y que son fijas. Lo que hay especificado SIEMPRE va a estar y sin condiciones, porque para eso van a ser los test. Cosas como "puedes hacer tabla-por-subclase pero al final resulta que en estas bases de datos (X,Y,Z) no te va a funcionar" nunca pueden suceder
• Compatibilidad hacia atrás. Las herramientas O/R no suelen ser demasiado respetuosas con la compatibilidad hacia atrás. Por ejemplo, en Hibernate ni siquiera han hecho deprecated todos los cambios en las APIs que han modificado en la 2.0 ¿ Qué menos que en las versiones 1.2.X te adviertan de que esas cosas no te van a funcionar en la 2.0 ? Eso nunca va a pasar en las APIs oficiales de Java, ya que se juega el prestigio de una especificación y de muchas empresa.
• Foros: Normalmente hay mucha prepotencia en estos foros. Lo primero que me respondieron ante mi duda en la lista de Hibernate ( y fue el propio Gavin King fue ) después de haber explicado clara y educadamente mi problema fue : "Hibernate soporta eso. Obviamente estás haciendo algo mal". La respuesta fue de esas típicas en las que marcas sólo una parte de lo que ha escrito la otra persona y sueltas la perla de sabiduría dejando mal al supuesto pesado. Después de quejarme por ese tipo de respuestas tan constructivas el trato fue diferente. ¿ La ventaja de estos motores O/R ? Suelen ser proyectos Open Source y la respuesta es muy rápida, de hecho, fueron respuestas inmediatas.

Nada más. ¿ Qué opináis ? Hibernate y compañía son productos muy potentes, pero ...., visto lo visto, ¿ vale la pena jugarse las lentejas ?