E
Точно можно, почитай доку
Да вот что-то не мог найти в доке и в гугле про конкретно подобный случай. Нужно будет проверить вариант метода с возвратом
HashSet<T>, наверное должно сработать.Size: a a a
2020 January 16
I
Та будет что то findAllUniqueIdFromEntity
RS
Делал такое. нужно писать свою имплементацию Pageable. Там есть метод getOffset(), который и используется под капотом спринг-датой при формировании запроса. В стандартной имплементации возврвщается page * size, а в своей кастомной имплементации можно возвращать именно offset. И тогда pageable абстракция спринг-даты вполне работает и с оффсет-бэйзд пагинацией.
E
Та будет что то findAllUniqueIdFromEntity
Похоже что это
findDistinctBlaBla() будет, в доке нашёл такой пример. Спасибо за подсказку.VT
Ruslan Stelmachenko
Делал такое. нужно писать свою имплементацию Pageable. Там есть метод getOffset(), который и используется под капотом спринг-датой при формировании запроса. В стандартной имплементации возврвщается page * size, а в своей кастомной имплементации можно возвращать именно offset. И тогда pageable абстракция спринг-даты вполне работает и с оффсет-бэйзд пагинацией.
ок, спасибо. Сейчас напишем
2020 January 17
Э
привет, я правильно понимаю, со spring boot отпала необходимость в tomcat?
VS
привет, я правильно понимаю, со spring boot отпала необходимость в tomcat?
он встроен в spring-boot-starter-web
VS
всмысле, томкат встроен
Э
он встроен в spring-boot-starter-web
именно эта библиотека кратко именуется spring web при создании проекта на start.spring.io?
Э
хм, спасибо, классная штука этот spring boot 👍
VG
Народ, привет.
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
АС
да, это гуд. Entity не должны использоваться за пределами сервисного слоя
АС
это немного увеличивает количество классов и писанины, но заметно снижает сложность системы и вероятность неочевидных поведений
OH
Народ, привет.
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
Добрый день! Само собой, что на клиент нужно отдавать не Entity, а DTO. Обратите внимание на Modelmapper для маппинга. Если отдавать Entity ещё и со связями OneToMany ManyToOne, то Jackson ругается. Можно конечно это обойти (см. аннотацию @ Jsonİgnore)
VG
не, не, тут вопрос был про кеш больше. entity на клиенты отдавать не надо
VG
то есть правильно сразу же создавать entity + domain, даже если могут дублировать друг друга?
АС
клиенты - имеется ввиду не клиенты приложения, а клиенты сервисного слоя
АС
то есть другие программные единицы
VG
да, я понимаю
РН
Народ, привет.
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
Нормальный подход?
Entity работают с repository, ответы из сервисов маппятся в dto для api, сервисы внутри себя работают с repository и другими сервисами.
Eсть кеширующий слой - redis. Поскольку кешировать сразу entity сложно из-за lazy initialization exception в связях, то пришлось писать промежуточный слой объектов - domain, которые создаются из entity и уже возвращаются из сервисов
кеш провайдеры для гибернейта рассматривал?