Как Spring Data JPA строит запросы по методам репозитория

Что проверяют

Понимаете ли вы, что имя метода разбирается на этапе старта, и знаете ли, где заканчиваются возможности этого механизма.

Как отвечать

При запуске Spring создаёт реализацию интерфейса репозитория. Имя каждого метода разбирается парсером: отбрасывается префикс (find, read, get, count, exists, delete), затем по ключевым словам строится дерево условий, которое превращается в запрос JPQL, а тот в SQL.

Разбор понимает свойства сущности и вложенные пути, а также операторы: And, Or, Between, LessThan, Like, StartingWith, In, IsNull, IgnoreCase, OrderBy. Параметры метода подставляются по порядку.

List<Job> findByCompanyNameAndSalaryGreaterThanOrderByCreatedAtDesc(String name, int salary);

Важные детали:

• ошибка обнаруживается на старте: опечатка в имени свойства валит контекст приложения, а не всплывает в рантайме. Это плюс, но и причина падений после переименования поля;
• имя быстро становится нечитаемым: три условия и сортировка дают строку в семьдесят символов. Тогда переходят на @Query или на Specification;
• возвращаемые типы: сущность, Optional, список, Page, Slice, поток, проекция в интерфейс или запись;
• пагинация и сортировка передаются объектом Pageable, и это работает вместе с разбором имени;
• @Query отменяет разбор имени и задаёт запрос явно, в том числе нативный, а для изменяющих запросов нужен @Modifying.

Где спотыкаются

Строят методы-монстры вместо явного запроса.

Забывают, что механизм не отменяет проблему N+1: связи всё равно тянутся лениво.

Переименовывают поле сущности и получают падение приложения на старте, не понимая причины.