Как-то особо не обращал на него внимание, а тут вдруг задумался и хочу понять, надо ли оно мне.

В целом пользуюсь JPA/Hibernate. Основное, что концептуально не нравится это заложенная мутабельность. Когда разработчики жаву тянут на immutable, это неудобно. Те же records использовать не получится. Ну и сложная это штука, Hibernate этот, по сути. Я с ним уже свыкся, а кто нет — могут ерунды наделать на ровном месте.

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

Основное, что мне не нравится в Spring Data, это их основная фича — вывод запроса из именования метода. Мне кажется это какой-то дичь. Любой нетривиальный запрос превращается в какую-то кашу. Поэтому Spring Data JPA я не пользуюсь.

Я плохо понял, как использовать Spring Data JDBC без этой "фичи".

Также могу отметить, что тупо писать везде чистый SQL я тоже не считаю разумным. iBatis-ом я пользовался, своё место у него есть, но в целом это неудобно. Маппинг из класса в таблицу нужен и автогенерация запроса на основе этого маппинга тоже нужна.

Вроде можно писать @Query("select * from table"), но вообще умные люди не советуют так делать. Если есть большие текстовые поля, которые в результате не используются (или вообще не замаплены), это замедлит такие запросы.

В целом мне хотелось бы писать запросы в стиле JPQL, возможно ограниченные. Есть ли такая фича в Data JDBC?

Здравствуйте, vsb, Вы писали:

vsb>Я плохо понял, как использовать Spring Data JDBC без этой "фичи".
vsb>Вроде можно писать @Query("select * from table"), но вообще умные люди не советуют так делать. Если есть большие текстовые поля, которые в результате не используются (или вообще не замаплены), это замедлит такие запросы.
Никто не заставляет "select *" писать
https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#jdbc.query-methods.at-query

interface UserRepository extends CrudRepository<User, Long> {

  @Query("select firstName, lastName from User u where u.emailAddress = :email")
  User findByEmailAddress(@Param("email") String email);
}

Или я не понял в чем твой вопрос.
Насчет Data JPA vs Data JDBC я скорее тоже за JDBC.

ЗЫЖ Кстати зря ты так уж против вывода запроса из именования метода, для простых случаев вполне годно.
ЗЗЫЖ Для совсем замороченных случаев, JdbcTemplate в руки и понеслась.

Здравствуйте, GarryIV, Вы писали:

GIV>Никто не заставляет "select *" писать
GIV>https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#jdbc.query-methods.at-query
GIV>

GIV>interface UserRepository extends CrudRepository<User, Long> {

GIV>  @Query("select firstName, lastName from User u where u.emailAddress = :email")
GIV>  User findByEmailAddress(@Param("email") String email);
GIV>}
GIV>

GIV>Или я не понял в чем твой вопрос.

Список полей писать тоже не вариант. Если я добавляю обычное поле в класс User, мне нужно, чтобы оно появилось во всех запросах автоматически, как это в Hibernate происходит.

В идеале я хочу что-то вроде @Query("select :User from user ..."), где синтаксис :User подставит все поля класса User, правильно обработав маппинги и тд.

GIV>ЗЫЖ Кстати зря ты так уж против вывода запроса из именования метода, для простых случаев вполне годно.

У меня плохой опыт. Когда понадобилось добавить поле enabled и переделать почти все имена запросов, получилась какая-то лажа. При том, что вызывающему коду про этот enabled знать особо и не надо, для него это значения не имеет. В итоге мне проще писать чуть больше бойлерплейта, зато без всякой магии.

Здравствуйте, vsb, Вы писали:

vsb>В идеале я хочу что-то вроде @Query("select :User from user ..."), где синтаксис :User подставит все поля класса User, правильно обработав маппинги и тд.

GIV>>ЗЫЖ Кстати зря ты так уж против вывода запроса из именования метода, для простых случаев вполне годно.

vsb>У меня плохой опыт. Когда понадобилось добавить поле enabled и переделать почти все имена запросов, получилась какая-то лажа. При том, что вызывающему коду про этот enabled знать особо и не надо, для него это значения не имеет. В итоге мне проще писать чуть больше бойлерплейта, зато без всякой магии.

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