| It is already known that FETCH joins and paging / limits do not play nicely together: See org.hibernate.hql.internal.ast.QueryTranslatorImpl#list
QueryParameters queryParametersToUse;
if ( hasLimit && containsCollectionFetches() ) {
boolean fail = session.getFactory().getSessionFactoryOptions().isFailOnPaginationOverCollectionFetchEnabled();
The following test-case demonstrates the problem
@Test
public void testCollectionFetchWithPaging() {
inTransaction(
session -> {
final String queryString = "select c from Customer c join fetch c.orders";
final List nonDistinctResult = session.createQuery( queryString ).list();
assertThat( nonDistinctResult.size(), CoreMatchers.is( 2 ) );
final List nonDistinctResultFirstResult = session.createQuery( queryString ).setFirstResult(0).list();
assertThat( nonDistinctResultFirstResult.size(), CoreMatchers.is( 2 ) );
}
);
}
The second assertion fails since the size is actually coming back as "1". By adding "setFirstResults(0)" to a query I would expect no impact in the final result. Is this assumption correct? The incorrect logic seems to be in org.hibernate.engine.spi.RowSelection#definesLimits where it should read
(firstRow != null && firstRow > 0)
The "firstRow" value should never be less than zero (enforced by the setter) so actually the problem only arises when the value of "firstRow" is precisely zero. |
