Warp Persist y Hibernate

He comenzado a jugar un poco con Google Guice, un contenedor liviano de inyección de dependencias y no pude evitar preguntarme como integrarlo con hibernate... la respuesta es AOP, y a través de warp persist es aun mas facil realizar el soporte transaccional.

En estos dias voy a subir un ejemplo a code.google para poder bajarlo facilmente.

Usar SQLQuery de HIbernate cuidadosamente

Hibernate provee dos API's de consultas de manera nativa a la base de datos, HQL y Criteria.
Pero también podemos hacer consultas en SQL nativo, pensado en funcionalidades muy particulares del RDBMS en el que estamos trabajando y que HQL o Criteria no nos provee en ese cierto contexto.

Esto puede ser tentador cuando uno da sus primeros pasos con este ORM, pues no habría que dedicar tiempo a aprender estos lenguajes y además podríamos probar nuestras consultas en alguna herramienta gráfica como DBVisualizer si fuera necesario, además de que cualquiera que no sea familiar a HQL o Criteria podría entender facilmente nuestra SQLQuery en plain SQL.

Pero hay algunas razones para evitar su abuso.

La SQLQuery de Hibernate bypassea la Cache de Session y realiza la consulta contra la base de datos.
Esto significa que si realizamos una consulta SQL en la misma transacción que hicimos un save o saveOrUpdate, los objetos grabados o actualizados en la Cache de Session no serán incluidos en el resultado de la consulta SQL.

La diferencia con querys en HQL o Criteria, es que éstas chequean las Cache de Session antes de ejecutar la consulta. Si hay objetos que ejecutar contra la base de datos, Hibernate hará automaticamente un session.flush() de la cache.
Esto implica que a diferencia de SQLQuery, HQL y Criteria incluirán los objetos en la Cache de Session el 100% de las veces.

Ahora bien, uno podría sugerir forzar el session.flush() antes de la SQLQuery y asunto arreglado... pero el problema es que el session.flush() es una operación costosa y HQL y Criteria (como tienen todos los objetos en la Cache de Session) simplemente pueden decidir cuando es necesario realizarlo.

Por qué Hibernate no crea bases de datos?

Una frase que me dijeron una vez y que siempre la tengo presente es "Lo único que Hibernate no va a hacer por vos, es crear la base de datos, todo lo demás lo podés hacer programaticamente". Para mi es casi poesía.
Y he visto gente que espera que Hibernate haga esto.
Alguien me sugirió que la respuesta a esta pregunta era simplemente "Por que Hibernate NO hace eso".
Tratemos de explicarlo al menos...
Primeramente, por que Hibernate es un ORM que esta pensado para trabajar con muchos RDBMS, por ende...como puedo decirle programaticamente cual es el motor que voy a usar? que yo sepa no se puede.
Segundo, Hibernate toma un hibernate.cfg.xml como punto de partida para hacer su trabajo (llevar mis objetos al mundo de las tablas) que si se fijan bien es ahí donde le digo con que rdbms, base de datos, usuario y contraseña se tiene que conectar... a una base de datos ya creada!

SchemaExport programaticamente en Hibernate

Hibernate posee una aplicación en su Core llamada hbm2ddl que es la que se encarga de la generación automática de ddl (CREATE, DROP y ALTER) a partir de la Configuration (o AnnotationConfiguration, si hacemos uso de las annotations que hibernate nos provee en su proyecto Hibernate Annotations).
Es posible, y de hecho muy util generar a partir de esto también un file donde esté nuestro ddl para la base de datos en la que se está trabajando.
Esto se podría lograr desde los ant tasks que Hibernate Tools trae para nosotros, pero también puede hacerse programática mente con la siguiente linea, colocada al final de, por ejemplo, nuestro método main().

new SchemaExport(cfg).setOutputFile("schema.ddl")
.create(true, true);