roundup-tracker / roundup / 8508976124

74%

Build Type

push

github

Committed by rouilj

Commit Message

issue2551328/issue2551264 unneeded next link and total_count incorrect

Fix: issue2551328 - REST results show next link if number of
     results is a multiple of page size. (Found by members of
     team 3 in the UMass-Boston CS682 Spring 2024 class.)

     issue2551264 - REST X-Total-Count header and @total_size
     count incorrect when paginated

These issues arose because we retrieved the exact number of rows
from the database as requested by the user using the @page_size
parameter. With this changeset, we retrieve up to 10 million + 1
rows from the database. If the total number of rows exceeds 10
million, we set the total_count indicators to -1 as an invalid
size.  (The max number of requested rows (default 10 million +1)
can be modified by the admin through interfaces.py.)

By retrieving more data than necessary, we can calculate the
total count by adding @page_index*@page_size to the number of
rows returned by the query.

Furthermore, since we return more than @page_size rows, we can
determine the existence of a row at @page_size+1 and use that
information to determine if a next link should be
provided. Previously, a next link was returned if @page_size rows
were retrieved.

This change does not guarantee that the user will get @page_size
rows returned. Access policy filtering occurs after the rows are
returned, and discards rows inaccessible by the user.

Using the current @page_index/@page_size it would be difficult to
have the roundup code refetch data and make sure that a full
@page_size set of rows is returned. E.G. @page_size=100 and 5 of
them are dropped due to access restrictions. We then fetch 10
items and add items 1-4 and 6 (5 is inaccessible). There is no
way to calculate the new database offset at:
@page_index*@page_size + 6 from the URL. We would need to add an
@page_offset=6 or something.

This could work since the client isn't adding 1 to @page_index to
get the next page. Thanks to HATEOAS, the client just uses the
'next' url. ... (continued)

Coverage Stats

17 of 17 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

17840 of 23802 relevant lines covered (74.95%)

3.0 hits per line