alek_sys 19 сен 2018 в 00:22

Представляем Spring Data JDBC

4 мин

46K

Программирование*Java*

Перевод

+11

Комментарии 34

norguhtar 19 сен 2018 в 06:54

Мы долго упорно трудились, чтобы JPA работал нормально и быстро, но куча народу не осилила в ORM и не умеет его готовить. По этому мы дадим упрощающий интерфейс к JDBC. Тут я делаю фейспалм.

-1

nikolayv81 19 сен 2018 в 08:54

Может немного не в тему, но мне почему-то кажется что это отличная возможность для проектов которые тянут данные не только из своей БД но ещё и из сторонних (к примеру большое реляционное хранилище), когда есть требования к написанию конкретных запросов (т.к. в том же Oracle можно легко "засуспендить" огромное количество пользователей "сожрав temp", при этом разделение ресурсов не всегда оправдано).

habradante 19 сен 2018 в 08:57

Чем JPA мешает вытянуть данные «не только из своей БД»? И как вообще подключение к БД влияет на выбор ORM?

nikolayv81 19 сен 2018 в 10:24

Я немного не про то, я про необходимость написания текста конкретных запросов, который гарантированно не будет изменён.
У нас есть постоянная "проблема" со сменой планов выполнения запросов по усмотрению планировщика, на больших объёмах это может быть весьма критично (от "запрос не завершиться в течении близжайших недель, до "закончится темповое пространство за 30 секунд и все запросы встанут), поэтому многие запросы вручную прибиты хинтами т.к. человек, иногда, знает немного больше про данные и особенности работы БД чем планировщик. При этом эти с большой вероятностью будут написаны не разработчиком приложения под Spring и их нужно будет использовать с минимальными затратами.

norguhtar 19 сен 2018 в 10:29

Это в JPA можно сделать без особых проблем.

norguhtar 19 сен 2018 в 08:57

Фишка в том что JPA слой позволяет спокойно работать напрямую с БД когда это надо :) Так что ну такое. Иногда может быть полезно, но это и раньше можно было делать. Тот же baltis к примеру.

vlanko 19 сен 2018 в 10:26

У меня был случай, когда Spring JPA пишет в базу в 30 раз медленнее, чем чистый JDBC.

norguhtar 19 сен 2018 в 10:29

Это вполне легко там можно получить если думать что ORM это же про объекты.

Mishiko 19 сен 2018 в 11:48

Я вижу тут профит в возможности безболезненного рефакторинга кода использующего Plain JDBC или Spring JDBC и, соответственно, в вовлечении его в Spring Data

norguhtar 19 сен 2018 в 11:49

Проще сразу на SpringData переехать. По затратам будет тоже самое.

alek_sys 19 сен 2018 в 13:26

Речь идёт не про «осилить» или нет, а просто о предоставлении очень простого механизма доступа к реляционным данным. По сути, Spring JDBC + SingleColumnRowMapper + базовое управление зависимостями (в виде aggregate roots из философии DDD) и все.

Часто всей мощи Hibernate не нужно, например в каком-то микросервисе.

norguhtar 19 сен 2018 в 13:35

Я как-то там не вижу сильно большого числа упрощений относительно SpringData. Точно так же надо добавлять POJO объект, точно так же надо добавить интерфейс, точно так же надо будет добавлять методы. Более того так-как DSL нет Query придется писать на любой чих.

alek_sys 19 сен 2018 в 14:17

Упрощения не в части API, это все остаётся таким же. Упрощение в том, что нет JPA и JPA провайдера, типа Hibernate.

norguhtar 19 сен 2018 в 14:19

А чем он мешает то? Память жрет на кеш?

alek_sys 19 сен 2018 в 14:23

Не мешает, но усложняет доступ к данным механизмами вроде кеширования, отслеживания изменений, сессионности, ленивой загрузки и т.п. В этом и суть нового модуля — надо все из Hibernate — берём Spring Data JPA. Не надо, но хочется Spring Data для реляционных баз — берём Spring Data JDBC.

norguhtar 19 сен 2018 в 14:25

Аналогичное было в spring 2.5 я про template если что. Тут немного row mapper обмазали. Ну разве что в микросервисах использовать. В любых сервисах где больше одной связки, уже ну такое будет. Много заката солнца в ручную.

nikolayv81 19 сен 2018 в 08:53

Ошибся веткой.

johndow 19 сен 2018 в 09:09

JDBI reinvented

-1

dididididi 19 сен 2018 в 09:27

Это статья какой-то пятилетней давности? В чем прикол?

«Мы намеренно решили отложить автоматическую генерацию запроса — популярную фичу Spring Data, когда SQL запрос генерится на основе имени метода — на будущие релизы.» — это ваще что?

norguhtar 19 сен 2018 в 10:30

Они пытаются быть ближе людям. Тот же spring boot в ту же степь.

alek_sys 19 сен 2018 в 13:21

Статья от позавчера, «прикола» никакого нет — просто новый модуль в Spring Data для легковесного доступа к данным.

Про генерацию запросов речь идёт о docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods.query-creation

foxyrus 19 сен 2018 в 09:29

Что на счет вызова хранимых процедур и возврата курсора?

alek_sys 19 сен 2018 в 23:18

Вызов хранимых процедур не должен быть проблемой, по сути такой же результат возвращается. А вот с курсорами за счет использования стандартного маппера уже сложнее. Возможно придется перекрывать дефолтную функциональность.

Hixon10 19 сен 2018 в 22:29

@Query("select id, first_name, dob from customer where upper(first_name) like '%' || upper(:name) || '%' ")
List<Customer> findByName(@Param("name") String name);

Тут есть одна неприятная проблема — компилятор не проверяет корректность выражения, даже названия колонок и таблицы. В условном JOOQ это не так.

alek_sys 19 сен 2018 в 23:15

Да, это верно, хотя актуально и для JPA, если не брать в расчет Criteria / Metamodel API. Вообще, задача проверки статической корректности работы с базой крайне сложная, поэтому чаще всего ее делегируют в рантайм (тесты). Тот же JOOQ не сможет гарантировать что схема БД соответствует сгенерированным классам.

Hixon10 19 сен 2018 в 23:37

В некотором роде, можно улучшить шанс на корректность классов против схемы БД, используя в паре с JOOQ какой-то механизм для миграций. Например, Flyway.

P.S. Надеюсь, когда-нибудь в Java появится возможность использовать нестроковые константы в аннотациях, но это будет совсем другая история. Всё API Спринга сразу бы преобразилось. Чего только стоят Аспекты

alek_sys 20 сен 2018 в 00:07

Да, Flyway и прочие помогают, но их ареал обитания все равно рантайм. Корректность классов против схемы БД нельзя проверить на этапе компиляции иногда чисто технически. Ведь не факт, что с разработческой машины или CI, где выполняется компиляция, есть доступ к базе, где схема может быть другой.

PS Справедливости ради, тут Hibernate может сильно помочь, у него есть режим проверки соответствия схемы модели на старте приложения.

PPS Сложность не-строковых (точнее, не-константных) аннотаций именно в этом и заключается. Вся эта динамика на этапе компиляции, в сущности, мало полезна, т.к. компиляция и запуск приложения обычно случаются в совершенно разных окружениях.