Spring Data integration requires order by item for unpaged repository invocation

[Mobe91]

Description

The blaze-persistence integration for Spring Data JPA currently requires at least one order by item for an unpaged repository invocation.

Given a repository

public interface DocumentViewRepository extends EntityViewRepository<DocumentView, Long> {
  Page<DocumentView> findByName(String name, Pageable pageable);
}

and the following repository invocation

documentViewRepository.findByName("name", Pageable.unpaged());

the invocation fails with the error

Pagination requires at least one order by item!

Expected behavior

The expected behavior is that the invocation works and produces a result without using pagination.

Actual behavior

The invocation fails.

Steps to reproduce

See issue description.

Environment

Version: 1.6.14
JPA-Provider: Hibernate 6.2

[Mobe91]

@beikov I have a prototypical fix for this that does not use a PaginatedCriteriaBuilder in case the org.springframework.data.domain.Pageable#isUnpaged returns true but uses a regular CriteriaBuilder. Let me know if you agree with this approach for the fix or if you see a better / more appropriate way.

In general, the order item restriction for pagination proves to be an obstacle for using a Blaze-Persistence repository as a drop-in replacement for a native Spring Data JPA repository.

[beikov]

I have a prototypical fix for this that does not use a PaginatedCriteriaBuilder in case the org.springframework.data.domain.Pageable#isUnpaged returns true but uses a regular CriteriaBuilder. Let me know if you agree with this approach for the fix or if you see a better / more appropriate way.

Sounds good to me.

In general, the order item restriction for pagination proves to be an obstacle for using a Blaze-Persistence repository as a drop-in replacement for a native Spring Data JPA repository.

It's kind of odd to use a Page as return type if no ordering is applied, just like it IMO doesn't make sense to do pagination based on values that don't form a unique tuple. With plain Spring Data, you might get rubbish results, so this check is an actual protection.

Since you can use both Blaze-Persistence and Spring Data JPA repositories, people can choose to continue using a broken Spring Data JPA based implementation, but I personally don't see such exceptions as a "problem" of the Blaze-Persistence integration. It's a user error which is not validated by Spring Data.