Ну судя по тому, что я вижу, это просто wrapper для запуска Postgres в рамках тестов + попытка реализовать свой AutoconfigureTestDatabase. В этом, конечно, нет ничего плохого, просто непонятно, какую проблему это решает, которую не решает стандартная тестовая библиотека Spring? И Flyway, и Liquibase @DataJpaTest конфигурирует.
Если уж хочется принести полноценный embedded postgres, я бы скорее порекомендовал TestContainers, там хотя бы будет изолированный сервер, а не просто запускалка локальной базы Postgres.
В общем случае @Entity не должна быть @Data классом, т.к. дата-классы это Value-objects, и, например, проверяют идентичность объектов по всем полям. Для entity же идентичность обычно значит совпадение ID или NaturalId, это важно для многих внутренних механизмов JPA.
Здесь Влад рассказывает как раз как правильно реализовать equals / hashCode.
Спасибо за статью! Пара моментов, больше для читателей, из того, что не упомянуто:
Самое важное — @ConfigurationProperties это не только про загрузку свойств из application.properties файла. Возможности Spring Boot Configuration гораздо шире — поддерживается 17 (!) разных источников свойств в строгом приоритете. Можно определить дефолт в application.properties и перекрыть его через переменную окружения, JVM properties, профиль, тестовые свойства и т.п. Что дает очень мощные возможности для переконфигурирования приложения в нужном окружении и сильно упрощает конфигурацию. А в дополнение — список источников еще и можно расширять, например, добавить Hashicorp Vault как бэкенд.
ConfigurationProperties аннотация — это часть Spring Boot, а не Spring Core
@SpringBootApplication аннотация включает ComponentScan, так что XML конфигурацию (да и любую конфигурацию) можно убрать и просто аннотировать классы @Component. Хотя некоторые разработчики предпочитают явную конфигурацию над автоматическим поиском компонентов.
Конфигурировать можно не только классы properties, а вообще любой бин — если совместить @Bean + @ConfigurationProperties или @Component + @ConfigurationProperties. По сути, все, что делает @EnableConfigurationProperties — это регистрирует бин указанного типа.
Field и Property injection это, все же, моветон, хотя и не запрещено.
Спасибо за статью, хотя, конечно, стоило бы ее вычитать и вычистить перед публикацией: опечатки, ошметки кода, "чесание репы" и выгрузка асинхронных результатов в HashMap чтобы сделать ответ блокирующим, немного смущают. Буду рад помочь, если нужен детальный фидбек.
Micronaut очень похож на Spring не случайно, они прямо пишут:
"Micronaut takes heavy inspiration from Spring, and in fact, the core developers of Micronaut are former SpringSource/Pivotal engineers now working for OCI"
Но если уж говорить про Micronaut, нужно упомянуть его killer feature — вся инъекция зависимостей там выполняется в compile time, использя annotation processor.
Unlike Spring which relies exclusively on runtime reflection and proxies, Micronaut, on the other hand, uses compile time data to implement dependency injection.
Что и хорошо, и плохо. Хорошо — время, потраченное в рантайме, например, при запуске, неплохо экономится (хотя еще надо замерить — насколько хорошо). Плохо — это же время тратится в compile time, т.е. чуда не произойдет, плюс все сложности работы с annotation processor, плюс совсем уж невероятный уровень магии.
Да, Flyway и прочие помогают, но их ареал обитания все равно рантайм. Корректность классов против схемы БД нельзя проверить на этапе компиляции иногда чисто технически. Ведь не факт, что с разработческой машины или CI, где выполняется компиляция, есть доступ к базе, где схема может быть другой.
PS Справедливости ради, тут Hibernate может сильно помочь, у него есть режим проверки соответствия схемы модели на старте приложения.
PPS Сложность не-строковых (точнее, не-константных) аннотаций именно в этом и заключается. Вся эта динамика на этапе компиляции, в сущности, мало полезна, т.к. компиляция и запуск приложения обычно случаются в совершенно разных окружениях.
Вызов хранимых процедур не должен быть проблемой, по сути такой же результат возвращается. А вот с курсорами за счет использования стандартного маппера уже сложнее. Возможно придется перекрывать дефолтную функциональность.
Да, это верно, хотя актуально и для JPA, если не брать в расчет Criteria / Metamodel API. Вообще, задача проверки статической корректности работы с базой крайне сложная, поэтому чаще всего ее делегируют в рантайм (тесты). Тот же JOOQ не сможет гарантировать что схема БД соответствует сгенерированным классам.
Не мешает, но усложняет доступ к данным механизмами вроде кеширования, отслеживания изменений, сессионности, ленивой загрузки и т.п. В этом и суть нового модуля — надо все из Hibernate — берём Spring Data JPA. Не надо, но хочется Spring Data для реляционных баз — берём Spring Data JDBC.
Речь идёт не про «осилить» или нет, а просто о предоставлении очень простого механизма доступа к реляционным данным. По сути, Spring JDBC + SingleColumnRowMapper + базовое управление зависимостями (в виде aggregate roots из философии DDD) и все.
Часто всей мощи Hibernate не нужно, например в каком-то микросервисе.
Он есть, только его не рекомендуется использовать иначе, как кэш. Т.е. надо всегда иметь в виду, что кэша может не быть — если джоб запущен на другом воркере и даже в рамках одного воркера.
Киллер фич есть несколько. Одна — что Concourse CI «нативен» для билд-монитора, т.е. его легко вывести на большой экран чтобы видеть текущий статус системы. Для этого не нужны плагины, это круто выглядит и красиво анимировано Вторая — что Concourse всеми силами навязывает модель «повторяемого» билда, например передавать данные между джобами можно только через ресурсы (которые персистентные), а каждый таск работает в одноразовом контейнере. Это не уникально, конечно, можно так же сделать в Дженкинс, но тут все изначально и by design. Например мы недавно полностью переключились с одного инстанса Конкурса на другой просто сменив target. Билд завёлся сразу, без трогания воркеров или АТС. Опять же, так можно где угодно, но Конкурс к этому активно подталкивает.
Ну судя по тому, что я вижу, это просто wrapper для запуска Postgres в рамках тестов + попытка реализовать свой AutoconfigureTestDatabase. В этом, конечно, нет ничего плохого, просто непонятно, какую проблему это решает, которую не решает стандартная тестовая библиотека Spring? И Flyway, и Liquibase
@DataJpaTestконфигурирует.Если уж хочется принести полноценный embedded postgres, я бы скорее порекомендовал TestContainers, там хотя бы будет изолированный сервер, а не просто запускалка локальной базы Postgres.
Продолжение готово https://habr.com/post/433958/, следующая статья тоже в процессе.
В общем случае
@Entityне должна быть@Dataклассом, т.к. дата-классы это Value-objects, и, например, проверяют идентичность объектов по всем полям. Для entity же идентичность обычно значит совпадение ID или NaturalId, это важно для многих внутренних механизмов JPA.Здесь Влад рассказывает как раз как правильно реализовать equals / hashCode.
Спасибо за статью! Пара моментов, больше для читателей, из того, что не упомянуто:
@ConfigurationPropertiesэто не только про загрузку свойств из application.properties файла. Возможности Spring Boot Configuration гораздо шире — поддерживается 17 (!) разных источников свойств в строгом приоритете. Можно определить дефолт в application.properties и перекрыть его через переменную окружения, JVM properties, профиль, тестовые свойства и т.п. Что дает очень мощные возможности для переконфигурирования приложения в нужном окружении и сильно упрощает конфигурацию. А в дополнение — список источников еще и можно расширять, например, добавить Hashicorp Vault как бэкенд.ConfigurationPropertiesаннотация — это часть Spring Boot, а не Spring Core@SpringBootApplicationаннотация включаетComponentScan, так что XML конфигурацию (да и любую конфигурацию) можно убрать и просто аннотировать классы@Component. Хотя некоторые разработчики предпочитают явную конфигурацию над автоматическим поиском компонентов.@Bean+@ConfigurationPropertiesили@Component+@ConfigurationProperties. По сути, все, что делает@EnableConfigurationProperties— это регистрирует бин указанного типа.Спасибо за статью, хотя, конечно, стоило бы ее вычитать и вычистить перед публикацией: опечатки, ошметки кода, "чесание репы" и выгрузка асинхронных результатов в HashMap чтобы сделать ответ блокирующим, немного смущают. Буду рад помочь, если нужен детальный фидбек.
Micronaut очень похож на Spring не случайно, они прямо пишут:
Но если уж говорить про Micronaut, нужно упомянуть его killer feature — вся инъекция зависимостей там выполняется в compile time, использя annotation processor.
Что и хорошо, и плохо. Хорошо — время, потраченное в рантайме, например, при запуске, неплохо экономится (хотя еще надо замерить — насколько хорошо). Плохо — это же время тратится в compile time, т.е. чуда не произойдет, плюс все сложности работы с annotation processor, плюс совсем уж невероятный уровень магии.
Немного промахнулся, см. ниже — есть базовый класс репозитория
PagingAndSortingRepositorydel
Да,
PagingAndSortingRepository(это не шутка, если что).Да, Flyway и прочие помогают, но их ареал обитания все равно рантайм. Корректность классов против схемы БД нельзя проверить на этапе компиляции иногда чисто технически. Ведь не факт, что с разработческой машины или CI, где выполняется компиляция, есть доступ к базе, где схема может быть другой.
PS Справедливости ради, тут Hibernate может сильно помочь, у него есть режим проверки соответствия схемы модели на старте приложения.
PPS Сложность не-строковых (точнее, не-константных) аннотаций именно в этом и заключается. Вся эта динамика на этапе компиляции, в сущности, мало полезна, т.к. компиляция и запуск приложения обычно случаются в совершенно разных окружениях.
Вызов хранимых процедур не должен быть проблемой, по сути такой же результат возвращается. А вот с курсорами за счет использования стандартного маппера уже сложнее. Возможно придется перекрывать дефолтную функциональность.
Да, это верно, хотя актуально и для JPA, если не брать в расчет Criteria / Metamodel API. Вообще, задача проверки статической корректности работы с базой крайне сложная, поэтому чаще всего ее делегируют в рантайм (тесты). Тот же JOOQ не сможет гарантировать что схема БД соответствует сгенерированным классам.
Я почти уверен, автоматическая генерация еще будет, просто не в этой версии.
Часто всей мощи Hibernate не нужно, например в каком-то микросервисе.
Про генерацию запросов речь идёт о docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods.query-creation
Это поменялось в версии 2. Обновил код для Spring Boot 2.
По умолчанию Spring Initializr не создает папок под View или контроллеры, он в принципе не навязывает никакую структуру.
Нужные Imports в IDEA можно добавить самому — просто поставить курсор на подчеркнутый символ, нажать Alt+Enter и выбрать 'Import ...'.
Ну и как план Б — исходный код этой статьи доступен на GitHub, вот например реализация
IndexController— https://github.com/alek-sys/spring-demo/blob/master/src/main/java/com/example/demo/IndexController.java