Как-то особо не обращал на него внимание, а тут вдруг задумался и хочу понять, надо ли оно мне.
В целом пользуюсь 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 в руки и понеслась.
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 знать особо и не надо, для него это значения не имеет. В итоге мне проще писать чуть больше бойлерплейта, зато без всякой магии.
Насколько я знаю из коробки нет решения, кастомное скорее всего можно сделать.
В первом случае препроцессить запрос и заменять * на список полей возвращаемого класса а во втором добавить условие в запрос.