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. But I am not going to cross that bridge without a concrete use case. This can also be handled client side by merging a short response with the next response and re-paginating client side. Also added extra index markers to the docs to highlight use of interfaces.py.

.. meta::
   :description:

     Original documentation of the Roundup Issue tracker. Includes
     historic Software Carpentry submissions and a short paper.

===================================
Software Carpentry and Short Papers
===================================

These papers are the original artifacts of Roundup.  They can't be
included easily in the table of contents for the documentation, so
they are referenced here.  All of these were written by Ka-Ping Yee,
the original architect of Roundup..

A few of the pages have been updated to correct links. However you may
still have to use the `wayback machine <https://wayback.archive.org>`_
to access some of the links on these pages. The papers in
chronological order are:

  * `See a short paper explaining Roundup <roundup_short_paper.html>`_

  * `See the original overview document for Roundup submitted to the
    Software Carpentry competition <original_overview.html>`_

  * `See the original specification document for Roundup submitted to the
    Software Carpentry competition <spec.html>`_