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.
No hay comentarios:
Publicar un comentario