Comments 34
Может немного не в тему, но мне почему-то кажется что это отличная возможность для проектов которые тянут данные не только из своей БД но ещё и из сторонних (к примеру большое реляционное хранилище), когда есть требования к написанию конкретных запросов (т.к. в том же Oracle можно легко "засуспендить" огромное количество пользователей "сожрав temp", при этом разделение ресурсов не всегда оправдано).
Я немного не про то, я про необходимость написания текста конкретных запросов, который гарантированно не будет изменён.
У нас есть постоянная "проблема" со сменой планов выполнения запросов по усмотрению планировщика, на больших объёмах это может быть весьма критично (от "запрос не завершиться в течении близжайших недель, до "закончится темповое пространство за 30 секунд и все запросы встанут), поэтому многие запросы вручную прибиты хинтами т.к. человек, иногда, знает немного больше про данные и особенности работы БД чем планировщик. При этом эти с большой вероятностью будут написаны не разработчиком приложения под Spring и их нужно будет использовать с минимальными затратами.
Часто всей мощи Hibernate не нужно, например в каком-то микросервисе.
«Мы намеренно решили отложить автоматическую генерацию запроса — популярную фичу Spring Data, когда SQL запрос генерится на основе имени метода — на будущие релизы.» — это ваще что?
Про генерацию запросов речь идёт о docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods.query-creation
@Query("select id, first_name, dob from customer where upper(first_name) like '%' || upper(:name) || '%' ")
List<Customer> findByName(@Param("name") String name);
Тут есть одна неприятная проблема — компилятор не проверяет корректность выражения, даже названия колонок и таблицы. В условном JOOQ это не так.
Да, это верно, хотя актуально и для JPA, если не брать в расчет Criteria / Metamodel API. Вообще, задача проверки статической корректности работы с базой крайне сложная, поэтому чаще всего ее делегируют в рантайм (тесты). Тот же JOOQ не сможет гарантировать что схема БД соответствует сгенерированным классам.
P.S. Надеюсь, когда-нибудь в Java появится возможность использовать нестроковые константы в аннотациях, но это будет совсем другая история. Всё API Спринга сразу бы преобразилось. Чего только стоят Аспекты
Да, Flyway и прочие помогают, но их ареал обитания все равно рантайм. Корректность классов против схемы БД нельзя проверить на этапе компиляции иногда чисто технически. Ведь не факт, что с разработческой машины или CI, где выполняется компиляция, есть доступ к базе, где схема может быть другой.
PS Справедливости ради, тут Hibernate может сильно помочь, у него есть режим проверки соответствия схемы модели на старте приложения.
PPS Сложность не-строковых (точнее, не-константных) аннотаций именно в этом и заключается. Вся эта динамика на этапе компиляции, в сущности, мало полезна, т.к. компиляция и запуск приложения обычно случаются в совершенно разных окружениях.
Немного промахнулся, см. ниже — есть базовый класс репозитория PagingAndSortingRepository
Да, PagingAndSortingRepository
(это не шутка, если что).
Представляем Spring Data JDBC