Converting List to Page Using Spring Data JPA

最后修改: 2023-08-02T09:16:49+00:00

1. Overview

In this tutorial, we’ll see how we can convert a List into a Page using Spring Data JPA. In Spring Data JPA applications, it’s common to retrieve data from a database in a pageable manner. However, there may be situations where we need to convert a list of entities into a Page object for use in a pageable endpoint. For example, we might want to retrieve data from an external API or process data in memory.

We’ll set a simple example to help us visualize the data flow and conversion. We’ll divide our system into RestController, Service, and Repository layers and see how we can work to convert a large set of data retrieved from the database as List into smaller, more organized pages using the pagination abstractions provided by Spring Data JPA. Finally, we’ll write some tests to observe the pagination in action.

2. Key Pagination Abstractions in Spring Data JPA

Let’s have a brief look at the key abstractions provided by Spring Data JPA that are used in producing paginated data.

2.1. Page

Page is one of the key interfaces provided by Spring Data to facilitate pagination. It provides a way to represent and manage large result sets returned from database queries in a paginated format.

We can then use the Page object to display the required number of records to the user and links to navigate to subsequent pages.

Page encapsulates details such as the content of the page, along with metadata involving pagination details such as page number and page size, whether there is a next or previous page, how many elements are remaining, and the total number of pages and elements.

2.2. Pageable

Pageable is an abstract interface for pagination information. The concrete class that implements this interface is PageRequest. It represents the pagination metadata, such as the current page number, the number of elements per page, and the sorting criteria*.* It’s an interface in Spring Data JPA that provides a convenient way to specify pagination information for a query or, in our case, to bundle the paging information together with the contents to create the Page from a List.

2.3. PageImpl

Finally, there’s the PageImpl class, which provides a convenient implementation of the Page interface that can be used to represent a page of results from a query, including the pagination metadata. It’s commonly used in conjunction with Spring Data’s repository interfaces and pagination mechanisms to retrieve and manipulate data in a pageable manner.

Now that we’ve got a basic understanding of the involved components, let’s set up a simple example.

3. Example Setup

Let’s consider a simple example of a customer information microservice, with a REST endpoint that can get paginated customer data based on the request parameters. We’ll set up the required dependencies first in the POM. The required dependencies are spring-boot-starter-data-jpa and spring-boot-starter-web, and we’ll also add spring-boot-starter-test for testing purposes:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependendencies>

Next. let’s set up the REST Controller.

3.1. Customer Controller

First off, let’s add the appropriate method with the request parameters that will drive our logic in the service layer:

@GetMapping("/api/customers")
public ResponseEntity<Page<Customer>> getCustomers(@RequestParam(defaultValue = "0") int page, @RequestParam(defaultValue = "10") int size) {

    Page<Customer> customerPage = customerService.getCustomers(page, size);
    HttpHeaders headers = new HttpHeaders();
    headers.add("X-Page-Number", String.valueOf(customerPage.getNumber()));
    headers.add("X-Page-Size", String.valueOf(customerPage.getSize()));

    return ResponseEntity.ok()
      .headers(headers)
      .body(customerPage);
}

*Here, we can see that the getCustomers method is expecting a ResponseEntity of type Page.*

3.2. Customer Service

Next, let’s set up our service class that will interact with the repository, convert the data into the required Page, and return it to the Controller:

public Page<Customer> getCustomers(int page, int size) {

    List<Customer> allCustomers = customerRepository.findAll();
//... logic to convert the List<Customer> to Page<Customer>
//... return Page<Customer>
}

Here, we’ve omitted the details, just focusing on the fact that the service calls the JPA repository and is getting a potentially large set of Customer data as List. Next, let’s look into the details of how we can use the JPA-provided API to convert this list into Page.

4. Converting List to Page

Now, let’s furnish the details of how the CustomerService can convert the List received from CustomerRepository into a Page object. Essentially, after retrieving a list of all customers from the database, we want to create a Pageable object using the PageRequest factory method:

private Pageable createPageRequestUsing(int page, int size) {
    return PageRequest.of(page, size);
}

Note that these page and size parameters are the ones passed down as request parameters from our CustomerRestController to CustomerService.

We’ll then split the large list of Customer into a sub-list. We need to know the start and end indices, based on which we can create a sub-list. This can be calculated using the getOffset() and getPageSize() methods of the Pageable object:

int start = (int) pageRequest.getOffset();

Next, let’s get the end index:

int end = Math.min((start + pageRequest.getPageSize()), allCustomers.size());

This sublist will form the content of our Page object:

 List<Customer> pageContent = allCustomers.subList(start, end);

Finally, we’ll create an instance of PageImpl. It will encapsulate the pageContent as well as the pageRequest  along with the total size of the List:

new PageImpl<>(pageContent, pageRequest, allCustomers.size());

Let’s put all the pieces together in one place:

public Page<Customer> getCustomers(int page, int size) {

    Pageable pageRequest = createPageRequestUsing(page, size);

    List<Customer> allCustomers = customerRepository.findAll();
    int start = (int) pageRequest.getOffset();
    int end = Math.min((start + pageRequest.getPageSize()), allCustomers.size());

    List<Customer> pageContent = allCustomers.subList(start, end);
    return new PageImpl<>(pageContent, pageRequest, allCustomers.size());
}

5. Testing the Service

Let’s write a quick test to see that the List is split into Page and that the page size and page number are correct. We’ll mock the customerRepository.findAll() method to return the list of Customer having size 20.

In the setup, we simply provide this list when findAll() is called:

@BeforeEach
void setup() {
    when(customerRepository.findAll()).thenReturn(ALL_CUSTOMERS);
}

Here, we’re constructing a parameterized test and asserting on the contents, content size, total elements, and total pages:

@ParameterizedTest
@MethodSource("testIO")
void givenAListOfCustomers_whenGetCustomers_thenReturnsDesiredDataAlongWithPagingInformation(int page, int size, List<String> expectedNames, long expectedTotalElements, long expectedTotalPages) {
    Page<Customer> customers = customerService.getCustomers(page, size);
    List<String> names = customers.getContent()
      .stream()
      .map(Customer::getName)
      .collect(Collectors.toList());

    assertEquals(expectedNames.size(), names.size());
    assertEquals(expectedNames, names);
    assertEquals(expectedTotalElements, customers.getTotalElements());
    assertEquals(expectedTotalPages, customers.getTotalPages());}

Finally, the test data input and output for this parametrized test are:

private static Collection<Object[]> testIO() {
    return Arrays.asList(
      new Object[][] {
        { 0, 5, PAGE_1_CONTENTS, 20L, 4L },
        { 1, 5, PAGE_2_CONTENTS, 20L, 4L },
        { 2, 5, PAGE_3_CONTENTS, 20L, 4L },
        { 3, 5, PAGE_4_CONTENTS, 20L, 4L },
        { 4, 5, EMPTY_PAGE, 20L, 4L } }
    );
}

Each test runs the service method with a different pair of page sizes (0,1,2,3,4), and each is expected to have 5 elements. We expect the total number of pages to be 4 since the total size of the original list is 20. Lastly, each page is expected to contain 5 elements.

6. Testing the Controller

Finally, let’s also test the Controller to make sure we’re getting the ResponseEntity<Page> back as JSON*.* We’ll use MockMVC to send a request to the GET endpoint and expect the paged response with the expected parameters:

@Test
void givenTotalCustomers20_whenGetRequestWithPageAndSize_thenPagedReponseIsReturnedFromDesiredPageAndSize() throws Exception {

    MvcResult result = mockMvc.perform(get("/api/customers?page=1&size=5"))
      .andExpect(status().isOk())
      .andReturn();

    MockHttpServletResponse response = result.getResponse();

    JSONObject jsonObject = new JSONObject(response.getContentAsString());
    assertThat(jsonObject.get("totalPages")).isEqualTo(4);
    assertThat(jsonObject.get("totalElements")).isEqualTo(20);
    assertThat(jsonObject.get("number")).isEqualTo(1);
    assertThat(jsonObject.get("size")).isEqualTo(5);
    assertThat(jsonObject.get("content")).isNotNull();}

Essentially, we are using a MockMvc instance to simulate an HTTP GET request to the /api/customers endpoint. We’re providing the query parameters page=1 and size=5. We then expect a successful response and a body containing page metadata and content.

Finally, let’s take a quick look at how converting a List to Page can benefit the API design and consumption.

7. Benefits of Using Page<*Customer*> Over List<*Customer*>

Choosing to return Page over the entire List as an API response in our example can have some benefits depending upon the use case. One of the benefits is optimized network traffic and processing. Essentially here, if the underlying data source returns a large list of customers, converting it to a Page allows the client to request only a specific page of results, rather than the entire list. This can lead to simplified processing at the client and reduce network load.

*Additionally, b***y returning a Page, the API provides a standardized response format that clients can easily understand and consume**. The Page object contains the list of customers for the requested page and metadata such as the total number of pages and the number of items per page.

Finally, converting the list of objects to a page provides flexibility in the API design. For example, the API can allow clients to sort the results by different fields. We can also filter the results based on criteria, or even return a subset of fields for each customer.

8. Conclusion

In this tutorial, we used Spring Data JPA to convert a List into a Page. We used the API provided by Spring Data JPA including Page, Pageable, and PageImpl classes. Finally, we briefly looked into some of the benefits of using Page over List.

In summary, converting a List to a Page in a REST endpoint provides a more efficient, standardized, and flexible way to handle large datasets and implement pagination in the API.

As always, the complete source code for this article can be found over on GitHub.