Тэги: SQL Collections Spring Boot Spring Data Spring Kotlin Hibernate PostgreSQL
В статье CrudRepository на Kotlin я рассказывал о том, как Spring Data позволяет быстро создавать слой взаимодействия с БД, поддерживающий все основные операции: создание, чтение, обновление и удаление. Для получения этой стандартной функциональности вам достаточно лишь определить класс-сущность, поля которой такие же как и в целевой таблице в БД, и интерфейс самого репозитория, который можно унаследовать от стандартного интерфейса CrudRepository. Реализовывать интерфейс при этом не нужно - Spring Data всё сделает за вас.
Помимо стандартных методов вы также можете добавить в этот интерфейс свои собственные. Причём если вы будете следовать соглашениям об именовании методов, то Spring Data будет автоматически генерировать по ним sql-запросы. То есть вы определяете запросы к БД в декларативном стиле. Это, во-первых, позволяет давать методам удобочитаемые имена, а во-вторых, позволяет абстрагироваться от конкретной СУБД и специфики написания запросов к ней.
Тэги: Spring Boot Spring Data SQL PostgreSQL Kotlin rest gradle Spring
Ранее я уже писал статью CrudRepository в Spring Data, в которой рассматривался пример rest-сервиса, работающего с базой данных. Теперь хочу показать аналогичный пример, но вместо Java написать его на Kotlin, который стремительно набирает популярность. Rest-сервис состоит из трёх слоёв: слой работы с БД, сервисный слой и контроллер. Мы пойдём последовательно по слоям, начиная с нижнего.
В качестве примера возьмём сервис, работающий с музыкальными группами. У группы есть три основных параметра: название, количество участников и дата основания. Структура таблицы в postgres может выглядеть следующим образом:
Тип данных serial означает поле, значение которого автоматически увеличивается на 1 с каждой новой записью.
Заготовку проекта удобно сгенерить через start.spring.io. Там достаточно выбрать тип проекта - gradle, язык - kotlin. В качестве dependency надо добавить Spring Web (функциональность rest-контроллеров), Spring Data JPA (работа с БД), Validation (валидация входящих rest-запросов) и PostgreSQL Driver (драйвер нашей СУБД). Затем нажимаем Generate - и вы уже скачали архив с заготовкой вашего проекта. В итоге файл build.gradle.kts в секции dependencies помимо стандартных должен также содержать следующие зависимости:
Тэги: Hibernate Spring Spring Boot rest SQL PostgreSQL gradle Spring Data Kotlin
Ранее я уже приводил пример в статье CrudRepository на Kotlin, как Spring Data позволяет легко выполнять основные операции над сущностями в БД. Теперь пойдём ещё дальше и рассмотрим как Spring Data Rest позволяет избежать написания контроллеров и сервисной логики. Исходники тестового проекта также прилагаются к этой статье и доступны на github.
Для начала создадим заготовку проекта. Проще всего это сделать с помощью сайта start.spring.io. В настройках выбираем в качестве языка Kotlin и в качестве сборщика Gradle. В dependency нам нужно последовательно добавить три зависимости: Spring Data JPA, Rest Repositories и PostgreSQL Driver. В итоге файл build.gradle.kts должен содержать, помимо стандартных, следующие зависимости:
Тэги: SQL PostgreSQL Spring Boot gradle Kotlin
Liquibase позволяет автоматизировать внесение обновлений в структуру БД. Каждое изменение описывается в декларативном стиле и версионируется. Обновления накатываются в заранее определённом порядке на данную БД, если они ещё не накатывались. Автоматизация процесса наката изменений на базу данных особенно важна, если у вас несколько различных экземпляров приложений и для каждого из них требуется поддерживать свою БД.
Рассмотрим работу с Liquibase на конкретном примере. С помощью сайта start.spring.io создадим заготовку нашего Spring Boot приложения (выбираем в качестве языка kotlin, а в качестве сборщика - gradle). В dependencies выберем компоненты Spring Web (функциональность rest-контроллеров), Spring Data JDBC (работа с БД), PostgreSQL Driver (драйвер нашей СУБД) и cам Liquibase Migration. В итоге файл build.gradle.kts в секции dependencies должен содержать следующие зависимости:
Тэги: Java 8 PostgreSQL Spring Boot rest Spring Hibernate Spring Data
В статье Hibernate и Spring Boot мы рассматривали использование Hibernate для того, чтобы не писать sql-запросы в слое доступа к данным. Сегодня мы пойдём ещё дальше и рассмотрим, как Spring Data может генерировать за вас сам слой доступа к данным со всеми методами, которые вам нужны в сервисном слое.
В качестве примера возьмём сущность «Страна» с её названием в качестве единственного параметра и на примере этой сущности шаг за шагом создадим все необходимые операции для поиска, добавления, редактирования и удаления этой сущности. В СУБД postgres надо создать следующую таблицу:
Теперь создадим типовой maven-проект и добавим в pom.xml необходимые зависимости. Полную версию файла можно посмотреть на github.
spring-boot-starter-web отвечает за обработку http-запросов, а spring-boot-starter-data-jpa предоставляет функционал доступа к данным. Также мы добавляем драйвер для работы с целевой СУБД.
Тэги: Spring Boot maven PostgreSQL rest Spring Java Hibernate
Ранее мы уже рассматривали, как работать с базой данных через jdbc в статье Работа с БД в Spring Boot на примере postgresql. А сегодня возьмём Hibernate - самый популярный фреймворк для работы с БД - и убедимся, что он значительно облегчает реализацию типовых операций над сущностями.
Предположим, в БД у нас есть две сущности: страна и город. В одной стране может быть несколько городов (отношение «один-ко-многим»). Структура таблиц выглядит примерно так:
И мы хотим совершать типовые действия над этими сущностями: просмотр всего списка, поиск по id, добавление, обновление и удаление записей. Для этого создадим типовой Spring Boot проект. В pom-файле нужно прописать следующий parent:
Тэги: Spring Boot Java PostgreSQL
В предыдущих статьях мы уже создавали rest-приложение (Spring Boot Restful Service, Работа с БД в Spring Boot на примере postgresql). А теперь давайте рассмотрим, как работать с датой и временем в Spring Boot на уровне rest-запросов и на уровне БД.
Предположим, перед нами стоит задача фиксировать в специальной таблице все действия пользователя (регистрация, вход, выход и т.п.) Таблица для СУБД Postgres в самом простом случае будет выглядеть так:
Тип serial представляет собой поле, которое автоматически увеличивается на единицу для каждой новой записи, поэтому его удобно использовать в качестве первичного ключа для записи.
Тип timestamp without time zone позволяет хранить метку времени без привязки к часовому поясу.
user_id и action_type представляют собой числовые id пользователя и тип действия соответственно. В реальном приложении каждое из них должно быть внешним ключом на соответствующие таблицы, но в нашем примере для простоты такой привязки нет.
Тэги: PostgreSQL
Для того, чтобы открыть доступ по локальной сети с других машин к БД, которая развёрнута на данной, нужно отредактировать два файла: postgresql.conf и pg_hba. Привожу пример для своей операционной системы, основанной на Linux (Ubuntu) и postgresql 9.5.
В файле /etc/postgresql/9.5/main/postgresql.conf находим строку
и раскомментируем её (убираем решётку в начале строки) или добавляем, если такой строки в этом файле нет.
Данный параметр говорит о том, чтобы обрабатывать все запросы, приходящие извне. В противном случае будут обрабатываться только локальные запросы.
Затем в файле /etc/postgresql/9.5/main/pg_hba.conf с правами администратора нужно указать, какие хосты имеют право подключаться к указанной БД и каким образом обеспечивается безопасность подключения.
Тэги: PostgreSQL
Рассмотрим составление рекурсивных запросов на PostgreSQL для иерархических данных на примере следующей таблицы:
Здесь поле parent_id содержит номер записи, которая является родительской по отношению к данной. Если parent_id = null, считаем, что это - корневой элемент иерархии.
Заполним таблицу данными:
Теперь составим запрос для прохода по этой иерархии, от элемента с именем subitem1 до root. На каждой итерации будем добавлять новую строку во временную таблицу temp1.
Тэги: PostgreSQL
Для создания полного бэкапа базы на postgres воспользуемся утилитой pg_dump. Бэкап представляет собой текстовый файл с sql-синтаксисом. При этом данные вставляются в более компактном виде.
Перейдём в целевой каталог, в котором планируется сохранить файл бэкапа. Затем выполняем команду:
Разумеется, подключиться можно как к локальной базе, так и к базе, расположенной на сервере. После того, как файл создался, можем приступить к созданию копии.
Для начала создайте базу (её имя может быть любым), а также пользователя, имя которого должно совпадать с именем пользователя, который работает с исходной базой. Скорее всего, это имя, которое вы использовали для параметра -U в команде, указанной выше. Но точнее лучше посмотреть в полученном файле бэкапа. В скрипте создания таблиц можно увидеть строчку вида:
Kotlin, Java, Java 11, Java 10, Java 9, Java 8, Spring, Spring Boot, Spring Data, SQL, PostgreSQL, Oracle, Hibernate, Collections, Stream API, многопоточность, Apache, maven, gradle, JUnit, ООП, алгоритмы, головоломки, rest