PR1: Added pagination in the house table layer for get all tables/databases #320
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Issue] Briefly discuss the summary of the changes made in this
pull request in 2-3 lines.
This PR adds pagination in the house table layer for get all tables/databases. Openhouse data access layer (house tables) uses Spring data JPA repository i.e. CrudRepository. However, CrudRepository does not support pagination and sorting capability. PagingAndSortingRepository which extends CrudRepository (prior to Spring 3.0) supports pagination. We are currently using spring boot 2.7.8. So by extending all our repositories to PagingAndSortingRepository we don't lose any of the existing behaviours and we gain paging and sorting capability on top of existing JPA repositories. JpaRepository which in turn extends PagingAndSortingRepository and comes with more advanced features which we don't need. So extending PagingAndSortingRepository is the best option for achieving pagination with sorting.
Backward compatibility:
We want to keep the existing APIs while pagination is ramped. API signature changes with pagination and so new APIs and methods are added to ensure that existing APIs work as expected.
Pagination:
A new API endpoint
/v1/hts/tables/query
is added for supporting pagination for user tables. The API accepts search parameters and pagination parameters. The pagination parameter includespage
,size
andsortedBy
fields such astableId
,databaseId
etc. Sorting is imported for pagination to work effectively. Unsorted data could lead to invalid results per page. All the pagination parameters have defaults if not provided. Page starts with 0 and the default value for page size is 50. Default sorting is provided ondatabaseId
. All sorting order is ascending and sort order is not part of the API parameter. Sort order can be included in future if needed.Pagination changes include only user tables in this PR. Pagination for jobs and feature toggle APIs are not part of this PR. They can be included in future if needed.
New HTS API
A new API called
getPaginatedUserTables
is added in the HTS layer with end point/v1/hts/tables/query
. This API accepts search parameters and pagination parameters as mentioned above. This API returns a list of tables/databases depending on search parameters and the behaviour is same as exitinggetUserTables
API. The response object remains same as the existing object for existing API i.e.GetAllEntityResponseBody
. A new parameter calledpageResults
is added to include pagination results. Pagination results are represented byPage
(org.springframework.data.domain.Page
). ThepageResults
contains contents (contains search results), pageable (for pagination related metadata), total pages, total elements and some additional parameters such as last to represent if the page is the last page.Next PR:
The next PR would include pagination changes in the tables layer and internal catalog layer.
Changes
For all the boxes checked, please include additional details of the changes made in this pull request.
Testing Done
Tested using local docker for HTS layer changes for pagination.
Pagination support for list databases:
There are 3 databases using existing list databases call
Existing list databases API call:
List databases API using pagination
Query for 1st page:
Query for 2nd page:
Existing list tables API call:
List tables API using pagination
Query without specifying pagination params using new API uses default values:
Query for 1st page:
Query for the 2nd page:
Query for the 3rd page:
Query for the 4th Page (page results are empty as expected and last page flag is true):
For all the boxes checked, include a detailed description of the testing done for the changes made in this pull request.
Additional Information
For all the boxes checked, include additional details of the changes made in this pull request.