| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Hibernate tuple |
| Автор: sergioK1 25.2.2021, 16:55 |
| Всем привет, лет 6 не работал с этим , счас смотрю есть Tuple, мне надо сделать запрос и результат поместить в свой обьект не связянный с базой как тут https://www.sql2o.org/, делать как раньше view и результат мапить не очень хочеться. |
| Автор: LSD 3.5.2021, 12:56 |
| Если у тебя Спринг, то можно просто интерфейс определить и @Query в репозитории. И Спринг сделает за тебя магию и вернет интерфейс. |
| Автор: sergioK1 8.9.2021, 10:53 | ||
Главная проблема спринга это то что возвращаемый обьект должен быть Entity, поэтому сложный join где поля из разных таблиц, им не сделаешь, как и динамический, персистент уровень это overhead . |
| Автор: LSD 13.9.2021, 19:24 | ||
Нет не должен. https://stackoverflow.com/questions/36328063/how-to-return-a-custom-object-from-a-spring-data-jpa-group-by-query. В nativeQuery можно любой запрос писать, хоть джойны, хоть групбаи, главное чтобы имена столбцов совпадали с именами геттеров. |
| Автор: Старовъръ 16.9.2021, 19:53 | ||||
Hibernate так же легко работает с не-Entity. Можно хоть нативные запросы, хоть через select new если эта таблица уже замаплена на какой-то Entity:
|
| Автор: sergioK1 15.11.2021, 00:50 | ||||||
Я так и делаю , получаю ResultSet и маплю его как мне надо, в варианте session.createQuery("select new blah.SomeClass(e.id, e.name) from SomeEntity e"); таблица должна быть замаплена , в случае с Join мне надо сначала делать view а потом мапить на него свой обьект , зчем такие сложности ? ORM это дурацкая идея , придуманная 20лет назад для защиты от ошибок при написание собсвенных баз данных, счас такие давно никто пишет, потому и добавили JdbcTemplate в Big Data вообще никаких ORM . Сначала берем данные из источника , потом думаем как его положить в обьект , и надо ли оно вообще. А то особо умные архитекторы сначала получают Entity а потом переписывают в DTO, абсолютно лишнее. Добавлено через 2 минуты и 36 секунд
если у тебя 15 плей то будешь все 15 передавать в конструкторе ? |
| Автор: LSD 13.12.2021, 12:17 | ||
Для native queries нужен только интерфейс, имплементацию спринг сделает. Для JPQL да нужно 15 полей, но есть же ломбок, есть рекорды, на худой конец идея умеет генерить весь бойлерплейт код. |
| Автор: sergioK1 14.12.2021, 16:54 | ||||
Да зачем мне делать двойную работу? В дебагере ты свой native queries не поменяешь , и будешь перезапускать аппликацию, никакого бойлерплейт кода, что нужно генерить и зачем ? Написал чвери в тоде или еще где , в код перенес ( можно и в файл ) а repository не знает с какой базой работать, Потому что кривыми руками сделан  |
