✨ Spring Tips: Переопределение свойств через переменные окружения

Часто в файле application.properties (или application.yml) объявляются свойства, значения которых содержат переменные вида ${ENV_PROPERTY_KEY:defaultValue}:

spring.datasource.url=jdbc:postgresql://${POSTGRES_HOST:localhost}/${POSTGRES_DB_NAME:local_dev_db}
spring.datasource.username=${POSTGRES_USERNAME:root}
spring.datasource.password=${POSTGRES_PASSWORD:root}
spring.datasource.driver-class-name=org.postgresql.Driver

Такой подход позволяет переопределять свойства при запуске приложения в разных средах (local, test, prod и т.д.).

Например, если мы решили запустить наше приложение через Docker Compose, предварительно собрав его в Docker образ, то передача значений для объявленных нами переменных окружения будет выглядеть следующим образом:

spring_test_app:
  image: spring_test_app:latest
  build:
    context: .
    dockerfile: docker/Dockerfile
    args:
      DOCKER_BUILDKIT: 1
  restart: "no"
  
  # задаём конкретные значения тем самым переменным окружения
  environment:
    POSTGRES_HOST: postgres:5432
    POSTGRES_DB_NAME: test_stand_db
    POSTGRES_USERNAME: admin
    POSTGRES_PASSWORD: admin
  ports:
    - "8080:8080"

В этом примере переменные из application.properties переопределяются через переменные окружения при запуске Docker контейнера.

Переопределение свойств напрямую

Но на самом деле, можно обойтись без дополнительных переменных в application.properties, переопределив Spring-свойства напрямую.

Теперь application.properties выглядит следующим образом:

spring.datasource.url=jdbc:postgresql://localhost:5432/local_dev_db
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=org.postgresql.Driver

А код сервиса нашего приложения в Docker Compose следующим образом:

spring_test_app:
  image: spring_test_app:latest
  build:
    context: .
    dockerfile: docker/Dockerfile
    args:
      DOCKER_BUILDKIT: 1
  restart: "no"
  environment:
    SPRING_DATASOURCE_URL: jdbc:postgresql://postgres/test_stand_db
    SPRING_DATASOURCE_USERNAME: admin
    SPRING_DATASOURCE_PASSWORD: admin
  ports:
    - "8080:8080"

Для spring.datasource.url, spring.datasource.username и spring.datasource.password будут использованы те значения, которые мы указали в Docker Compose файле.

За счёт чего это становится возможным?

Spring Boot использует определенный порядок загрузки свойств приложения, чтобы обеспечить разумное переопределение значений. Переменные окружения загружаются позже и перезаписывают свойства, заданные в application.properties. Полный порядок загрузки можно найти в документации.

Relaxed Binding в Spring Boot

Кстати, обратите внимание на стиль написания названий свойств. Spring Boot использует концепцию Relaxed Binding, которая позволяет указать название свойства без полного совпадения. Например:

@ConfigurationProperties(prefix = "my.main-project.person")
class MyPersonProperties {
 var firstName: String? = null
}

Для этого класса можно использовать следующие стили именования свойств:

- my.main-project.person.first-name — Kebab стиль для .properties/.yaml файлов
- my.main-project.person.firstName — CamelCase стиль
- my.main-project.person.first_name — Underscore стиль
- MY_MAINPROJECT_PERSON_FIRSTNAME — Uppercase + Underscore стиль для переменных окружения. При использовании Uppercase + Underscore стиля следует учитывать, что многие операционные системы ограничивают имена переменных окружения. Например, в Linux переменные могут содержать только буквы (a-z, A-Z), цифры (0-9) и символ подчеркивания (_). Подробнее читайте в документации.

В приведённом выше примере с Docker Compose файлом мы как раз воспользовались Uppercase + Underscore стилем, чтобы указать значения для нужных нам свойств. Именно такой вариант именования переменных окружения является негласным для Linux.

Ставь 🔥 если знал про это и 🤔 если слышишь впервые)

#SpringBoot #SpringTips

✨ Spring Tips: Рекурсивные запросы в Hibernate

Рекурсивные запросы в SQL очень полезны при работе с иерархическими или графовыми структурами данных. Конструкция WITH, введенная в SQL:1999, позволяет задавать Common Table Expressions (CTE), которые представляют собой именованные подзапросы. CTE упрощают сложные запросы, улучшают их читаемость и, что самое важное, позволяют нам реализовать рекурсию.

Рассмотрим таблицу, которая хранит информацию о сотрудниках и их менеджерах:

CREATE TABLE employees (
  employee_id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL,
  employee_name VARCHAR(255),
  manager_id INTEGER,
  CONSTRAINT pk_employees PRIMARY KEY (employee_id)
);

ALTER TABLE employees ADD CONSTRAINT 
FK_EMPLOYEES_ON_MANAGER FOREIGN KEY (manager_id) 
REFERENCES employees (employee_id);

Эта таблица представляет собой список сотрудников, где у каждого сотрудника есть уникальный идентификатор (employee_id), имя (employee_name) и ссылка на менеджера (manager_id). Поле manager_id является внешним ключом, ссылающимся на employee_id в той же таблице, что позволяет создать иерархическую структуру, где один сотрудник может быть менеджером для других.

Предположим, что нам нужно выбрать всех подчиненных определенного менеджера. Для решения этой задачи мы можем использовать рекурсивный SQL запрос:

WITH RECURSIVE EmployeeHierarchy AS (
    -- Базовый случай: начнем с верхнего уровня менеджера
    SELECT employee_id, employee_name, manager_id
    FROM employees
    WHERE manager_id = :id

    UNION ALL

    -- Рекурсивный случай: найдем всех сотрудников, подчиненных найденным ранее сотрудникам
    SELECT e.employee_id, e.employee_name, e.manager_id
    FROM employees e
    INNER JOIN EmployeeHierarchy eh ON e.manager_id = eh.employee_id
)

SELECT *
FROM EmployeeHierarchy;

До выхода версии Hibernate 6.2, для выполнения подобных запросов приходилось использовать nativeQuery. Пример с использованием entityManager выглядит следующим образом:

var sql = {SQL-запрос, представленный выше};

var employees = entityManager.createNativeQuery(sql, Employee.class)
        .setParameter("id", 1)
        .getResultList();

Либо так, если используется Spring Data JPA:

public interface EmployeeRepository extends JpaRepository<Employee, Integer> {
    @Query(value = "{SQL-запрос, представленный выше}", nativeQuery = true)
    List<Employee> findAllEmployeesByManagerIdSQL(@Param("id") Integer id);
}

List<Employee> employees = employeeRepository.findAllEmployeesByManagerIdSQL(1);

С выходом Hibernate 6.2, появилась возможность писать рекурсивные запросы, используя HQL. Запрос, представленный выше, теперь можно написать так:

String jpql = """
        WITH EmployeeHierarchy AS (
            SELECT e.employeeId AS id, e.employeeName AS name, e.manager AS mgr
            FROM Employee e
            WHERE e.manager.id = :id
        
            UNION ALL
        
            SELECT e.employeeId, e.employeeName, e.manager.id
            FROM Employee e
            JOIN EmployeeHierarchy eh ON e.manager.id = eh.id
        )
        SELECT new Employee(
            eh.id,
            eh.name,
            eh.mgr
        )
        FROM EmployeeHierarchy eh
        """;

var employees = entityManager.createQuery(jpql, Employee.class)
        .setParameter("id", 1)
        .getResultList();

А также со Spring Data JPA:

public interface EmployeeRepository extends JpaRepository<Employee, Integer> {
    @Query(value = "{JPQL-запрос, представленный выше}")
    List<Employee> findAllEmployeesByManagerIdJPQL(@Param("id") Integer id);
}

List<Employee> employees = employeeRepository.findAllEmployeesByManagerIdJPQL(1);

Как можно заметить, синтаксис HQL и SQL запросов довольно сильно похож. Но есть некоторые различия:

* В отличие от стандартного SQL, в Hibernate нет необходимости использовать ключевое слово RECURSIVE
* В Hibernate имена атрибутов CTE задаются через псевдонимы в выражении SELECT. Другими словами, в заголовке CTE имена не указываются.

#SpringTips #Hiberante #CTE

😡 Spring Data JPA: Проблема N+1 и один из способов её решения

Одной из часто обсуждаемых тем на собеседованиях по Spring Data JPA является проблема N+1 и возможные способы её решения. Многие отвечают, что её можно решить с помощью join fetch или @EntityGraph. Однако это не всегда так.

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

@Query("""
    select distinct a
    from Author a
    left join fetch a.books
""")
List<Author> findAllFetch();

@EntityGraph(attributePaths = {"books"})
@Query("""
    select distinct a
    from Author a
""")
List<Author> findAllFetch();

Но что если нужно выбрать только часть данных, например, постранично? Тогда запросы будут выглядеть так:

@Query("""
    select a
    from Author a
    left join fetch a.books
""")
Slice<Author> findAllFetch(Pageable page);

@EntityGraph(attributePaths = {"books"})
@Query("""
    select distinct a
    from Author a
""")
List<Author> findAllFetch(Pageable page);

Проблема в том, что когда мы используем Pageable, Hibernate сначала загрузит все записи в память, а затем отсортирует их. Это может привести к OutOfMemoryError и/или серьёзной деградации производительности.

В защиту Hibernate отметим, что столь неоптимизированное действие он не станет выполнять "втихую" и выведет следующий warning в логах:

WARN: HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!

Более того, указав следующее свойство в application.properties/yaml, Hibernate и вовсе начнёт падать с JpaSystemException:

spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true

Как же на самом деле стоит решать проблему N+1?

Правильное решение — использование аннотации @BatchSize:

@Entity
public class Owner extends Person {
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "owner")
    @BatchSize(size = 50)
    private List<Pet> pets = new ArrayList<>();
}

Если коллекций много, можно настроить глобальный размер выборки в файле application.properties/yaml:

spring.jpa.properties.hibernate.default_batch_fetch_size=50

С использованием @BatchSize или глобального свойства запросы можно переписать следующим образом:

@Query("""
    select a
    from Author a
""")
Slice<Author> findAllFetch(Pageable page);

List<Author> findAll(Pageable pageable);

Вывод

Используйте @BatchSize или spring.jpa.properties.hibernate.default_batch_fetch_size, чтобы избежать проблемы N+1 без загрузки избыточного количества данных в память.

Стоит отметить, что используя этот подход важно помнить про необходимость обращения к элементам связанной коллекции в условиях наличия открытой транзакции, чтобы Hibernate смог загрузить необходимые данные. Несмотря на то, что spring.jpa.open-in-view=true позволяет нам быть уверенными в наличии открытой транзакции, он не является рекомендуемым.

Для более глубокого понимания оптимизации запросов рекомендуем ознакомиться с докладом экспертов сообщества Spring АйО – Ильи и Фёдора Сазоновых, с которым они выступали на последнем JPoint.

#SpringTips #JPA #DB

🦥 Аннотация Lazy как спасение от циклических зависимостей

В прошлом посте мы подробно разобрали, как @Lazy помогает экономить ресурсы и ускорять старт приложения. Но забыли упомянуть ещё один крайне полезный кейс применения этой аннотации — борьбу с циклическими зависимостями.

Если в приложении бин A зависит от бина B, а бин B в свою очередь зависит от A — вы получите классическую circular dependency. Spring просто не сможет создать такие бины через конструкторы. Однако, если применить @Lazy на одном из аргументов, Spring обернёт зависимость в прокси и разорвёт цикл.

@Service
public class ServiceA {
    private final ServiceB serviceB;

    public ServiceA(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

Важно: @Lazy здесь влияет только на точку инжекции, а не на весь бин. Оба бина будут инициализированы жадно, но зависимость будет подгружена позже.

Если же вы хотите, чтобы инициализация бина проходила лениво (при первом обращении к бину), то отметьте аннотацией @Lazy и сам бин тоже:

@Lazy
@Service
public class ServiceB {
    // ...
}

⚠️ Использование свойства: spring.main.allow-circular-references=true

Это ещё один способ разрешить циклы на уровне конфигурации. Spring сам предложит это в логах, если столкнётся с циклом:

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

Но будьте осторожны:
– Это работает только с field-based и setter-based инжекцией
– Если используете constructor-based инжекцию, то приложение по прежнему не запустится, лишь немного изменится сообщение в логах
– До Spring Boot 2.6 это поведение было включено по умолчанию — после обновления многие столкнулись с неожиданными фейлами.

Поэтому такой подход стоит рассматривать как временную меру, а не как архитектурное решение.

#SpringTips #Lazy