Ответ 1
У нас та же дилемма в нашем проекте.
Проект действительно сложный: 90% объектов генерируются динамически; реализован уровень API выше API-интерфейсов Hibernate, тяжелого DAO и уровня обслуживания, который очень широко используется; наша версия спящего режима исправлена много раз, чтобы поддерживать определенную функциональность (например, START WITH
/CONNECT BY
, ARRAY
type in oracle и т.д.); postgresql и oracle используются как альтернативно, так и т.д.
Новый API JPA был бы очень полезен для нас. Нам нужна возможность использовать функции на уровне API критериев (а не HQL) (например, NVL/coalesce
для каких-то причин производительности, substring
, trim
и т.д.).
Кроме того, нам нужен Hibernate Envers, доступный только для реализации "EntityManager
" JPA.
Несчастливо в соответствии с нашим результатом исследования нет возможности использовать API-интерфейс JPA от родного Hibernate. Envers также нельзя использовать. Проект Hibernate постоянно развивается и получает новые возможности. Переход к новым версиям спящего режима - очень сложная задача для нас. И мы очень обеспокоены неспособностью использовать многие новые функции новых версий после миграции и расти с помощью этой базовой структуры.
Поэтому мы рассмотрим два возможных способа для нас: используйте SQLCriterion
с собственной реализацией Expression
(разрешите имена столбцов с помощью CriteriaQuery
и переведите на SQL) или перейдите на "EntityManager
" /CriteriaBuilder
. Второй способ выглядит как неизбежный. Но переход на реализацию JPA приносит много скрытых проблем, которые разрушают наш проект.
Если мы выберем миграцию, и это будет полезно, я оставлю здесь, с какими проблемами мы будем бороться в этой деятельности.