Avoid obsolete `null` check for `DefaultedPageable`

[j1myx]

I was looking for a way to make the endpoint return the data without paging, and since the documentation doesn't say anything about it, I started exploring the source code and I found something curious that I hope can tell me the reason why:

In the source code, precisely in the controller, it seems to provide a solution to my need, in which it is indicated that if the "pageable" property of the "pageable" object is null, all the data will be returned without paging. However, when exploring the "pageable" object, I am surprised that it will never be null, thus the endpoint will never return unpaged data.

Code snippet where the unnecessary condition is made:

Iterable<?> results = pageable.getPageable() != null
		? invoker.invokeFindAll(pageable.getPageable())
		: invoker.invokeFindAll(sort);

Full source code: https://github.com/spring-projects/spring-data-rest/blob/main/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/RepositoryEntityController.java
Line: 197

Fragmento de la clase DefaultedPageable donde se aprecia que la propiedad plegable nunca será nulo:

public final class DefaultedPageable {
      private final Pageable pageable;
      private final boolean isDefault;

      public DefaultedPageable(Pageable pageable, boolean isDefault) {
            Assert.notNull(pageable, "Pageable must not be null");

            this.pageable = pageable;
            this.isDefault = isDefault;
      }
}

Full source code: https://github.com/spring-projects/spring-data-rest/blob/main/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/support/DefaultedPageable.java

Please could you tell me the reason why you put that unnecessary condition? If it is a problem, please tell me so that I can collaborate in the correction and thus the data can be returned without pagination.

[odrotbohm]

If you expose a PagingAndSortingRepository you indicate you wanted paginated access to the resource. Especially when it comes to collection-like HTTP resources, it is important to consider that as full collection access usually means reading the entire database table containing potentially millions of rows / instances. In other words: if you want full collection access, don't use a PagingAndSortingRepository.

You are right, that the guard is obsolete. It likely stems from the times we applied the defaults differently. I'll remove that.

[fmaximus]

My repositories are extending JpaRepository which extends ListPagingAndSortingRepository.
So I don't agree with the statement: if a repository supports paging, we only use paging.
Either a NonPagingJpaRepository needs to be created,
or the original snippet should check Pageble.unpaged() instead of null.