Comments 12
А зачем вообще hibernate отправляет заведомо бесполезный запрос в бд в этом случае?
Конкретно здесь, может быть и можно было обойтись без запроса вообще. Наверно это не так просто сделать, когда это подзапрос, или какой-то более сложный кейс, с джоинами например.
Возможно, чтобы не городить множество оптимизаций на все случаи жизни, просто отключают ветку с помощью условия 1 = 0;
Этот вопрос надо не Hibernate адресовать, а Spring-у.
Осталось дождаться включения этого фикса в модуль Spring Data JPA.
А зачем дожидаться? Если можно просто обновить используемую версию хибера? Или автор свидетель тождественности спрингдатажпа и с хибером?
С in-clause
вообще лучше быть осторожным. В постгресе вроде бы ограничений нет, а в оракле, например, по дефолту не более 1000 аргументов -- соответственно, надо разбивать на чанки и конкатенировать результат.
Если бизнес-логика позволяет (как в данном конкретном случае), имеет смысл предварить в репозитории
interface ArticleRepository extends CrudRepository<Article, UUID> {
default List<Article> findByPublisherId(List<UUID> ids) {
if (ids.isEmpty()) {
return Collections.emtpyList();
}
return _findByPublisherId(ids);
}
@Query("from Article where publisherId in :ids")
List<Article> _findByPublisherId(List<UUID> ids);
}
Если метод совсем безобразно могут вызывать, ещё и проверку на null
добавить.
Не была печали, апдейтов накачали.
Сори, но зачем вам edge обновления, когда можно спокойно сидеть на стабильной ветке, просто со всеми патчами безопасности?
Катастрофа с Hibernate 6.5 при обновлении на Spring Boot 3.3.0