¿Cuándo debería una persona usar consultas nativas con JPA 2.0 en lugar de JPQL o CriteriaBuilder?

Question

Estoy muy confundido acerca de cuándo y cuándo no utilizar consultas nativas en JPA 2.0. Tenía la impresión de que el uso de consultas nativas podría hacer que no se sincronizara con el caché JPA. Si puedo lograr lo mismo con una consulta JPQL o CriteriaBuilder, ¿hay alguna buena razón para usar una consulta nativa? Del mismo modo, ¿hay algún peligro al usar una consulta nativa si puedo lograr lo mismo con JPQL o CriteriaBuilder? Y, por último, si existe el peligro de utilizar una consulta nativa en cuanto a la desincronización de la memoria caché JPA, ¿existiría el mismo peligro al ejecutar una consulta equivalente con JPQL o CriteriaBuilder?

Mi filosofía ha sido evitar las consultas nativas, pero seguramente hay momentos en que son necesarios. Me parece que si puedo hacerlo con JPQL o CriteriaBuilder, entonces debería hacerlo.

Gracias.

Answer 1

Estoy de acuerdo con su filosofía.

El principal problema con las consultas nativas, en mi humilde opinión, es la capacidad de mantenimiento. En primer lugar, en general son más complejas y más largas que las consultas JPQL. Pero también codifican nombres de tablas y columnas, en lugar de usar nombres de clases y propiedades.

Las consultas JPQL ya son problemáticas cuando se refactoriza, ya que codifican nombres de clases y propiedades en Strings. Pero las consultas nativas son aún peores, porque codifican nombres de tablas y columnas en todas partes.

No creo que las consultas de selección nativa sean un problema con respecto a la caché. Sin embargo, las consultas nativas de actualización, inserción y eliminación son un problema, ya que modifican los datos detrás de la memoria caché de primer y segundo nivel. Entonces estos pueden volverse obsoletos.

Otro problema es que sus consultas nativas podrían usar una sintaxis que sea reconocida por una base de datos pero no por otra, haciendo que la aplicación sea más difícil de migrar de una base de datos a otra.