Комментарии 8
Решение очень интересное. Убивает его только одно - отсылка некой таинственной статистики на третью сторону. На это прямо указывает их документация https://speedment.github.io/jpa-streamer/jpa-streamer/1.0.1/introduction/introduction.html#_phone_home:
JPAstreamer sends certain data back to Speedment’s servers as described here. If you wish to disable this feature, please contact us at info@jpastreamer.org.
Похоже на очень странную политику монитезации, которая не даст шансов широкому распространению продукта.
Имхо, недопустимо использовать библиотеку с представленными политиками, особенно если это не pet project. А делать это еще и без явного согласия - крайне некорректно. И на сколько я понимаю это блоккер для многих:
Кто согласен, апвотим здесь: https://github.com/speedment/jpa-streamer/issues/156.
Идея, крутая, но...
Мне не нравится введение дополнительных сущностей, бесполезных для бизнес-логики. Чем меня в своё время сильно бесила Java EE: вместо использования POJO-объекта на все случаи жизни с обычными конструкторами она вносила целый зоопарк всяких мета-сущностей (для базы Entity, для клиента DTO, для логики бизнес-классы, итого три класса на по сути одну сущность), с особыми правилами создания через всякие абстрактные фабрики декораторов и со своим жизненным циклом в каждом конкретном случае. Spring в какой-то степени смог обойтись без этой избыточности, хоть и не везде, потому и выиграл.
Вот и здесь вместо стнадратных функциональных интерфейсов Stream API предполагается использование каких-то очередных сгенерированных мета-классов и мета-методов.
Я не хочу работать над оптимизацией, я хочу, чтобы над оптимизацией работала библиотека.
Я хочу просто написать
var books = jpaStreamer.stream(Book.class)
.filter(x -> x.getYear() >= 2020)
.toList();и сразу получить
Hibernate: select book0_.id as id1_1_, book0_.author_id as author_i5_1_, book0_.price as price2_1_, book0_.title as title3_1_, book0_.year as year4_1_
from book book0_ where book0_.year>=?безо всякой мета-модели и паразитных сущностей.
Да, идея супер. В свое время, лет 5 назад, написал обертку на CriteriaBuilder в похожем стиле и теперь тащу ее из проекта в проект. Обертку писал, потому что с этими классами CriteriaBuilder, Root, Query сам черт ногу сломит в части их связи между собой. Хотелось построение запроса в Spring хоть отдаленно похожее на стиль SQL, а не вот это вот всё
А не лучше сразу на jooq перейти вместо этого всего?
Публикации
Можно ли подружить Stream API и JPA?