В классических требованиях к данным Hibernate Criteria я столкнулся с проблемой, когда мне нужно разбить на страницы результаты, поэтому мне нужно подсчитать общее количество строк и затем выбрать данные, разбитые на страницы.
Когда я вызываю
criteria.setProjection(Projections.rowCount());
int count = (int)criteria.list().get(0);
SQL-запрос точно такой, как я ожидал (от сущности, объединяется только с таблицами, которые присутствовали в критериях)
Но когда я выполняю
criteria.setMaxResults(pageable.getPageSize());
criteria.setFirstResult((int) pageable.getOffset());
criteria.setProjection(null);
criteria.setResultTransformer(Criteria.ROOT_ENTITY);
List<T> list = criteria.list();
мойSQL-запрос неожиданно изменился, и он преследует меня уже 3 дня.
Мало того, что запрос модифицируется, он просто объединяется с тем, что есть в моем классе объекта домена.И что меня больше всего беспокоит, так это даже СОЕДИНЕНИЕ с полями @OneToMany FetchType.LAZY, что делает мой ROOT_ENTITY вообще не отличимым.Я даже пытался поместить FetchMode.SELECT в свой класс сущностей домена, но это не помогло, hibernate просто игнорирует его.Я также попытался сделать это FetchMode.SELECT в критерии по criteria.setFetchMode("oneToManyProperty", FetchMode.SELECT), также игнорируется.
И поэтому мой общий счетчик равен N (он отличается), но мой окончательный список (со свойствами пагинации) может вернуть всеROOT_ENTITIES - то же самое (результат сопоставления с таблицей OneToMany), в результате чего сущности могут быть намного больше, чем N (в зависимости от того, сколько связей в БД).работать с разбиением на страницы, поскольку он просто «различается в фильтре памяти» после извлечения данных в память.
Как Hibernate может изменить этот запрос таким образом и просто игнорировать все стратегии выборки?