Change Details

**Problem** MediaWiki's `IndexPager` uses an `offset` URL parameter to determine where the //next// page should start. This strategy is described well in this [[ http://blog.vermorel.com/journal/2015/5/8/nearly-all-web-apis-get-paging-wrong.html | blog post ]]. The strategy has a lot of benefits. Primarily it is [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow | much faster ]] and prevents the user from getting duplicated results as new data is added to the table while they are paginating the results. However, there are some drawbacks. The biggest one is that it only works properly on unique database columns. If the sorting column is non-unique, it shows the user duplicate content, which is the very problem it seeks to solve. During the development of {T236225} it became clear that there is a need to be able to sort a paginated table of data on a non-unique field. **Proposed Solution** Obviously it is better for developers to use the [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/ | seek method ]] whenever possible (and that should be the default). However, MediaWiki, could provide the option of allow sorting by non-unique fields by using the SQL `OFFSET`. This is only a major performance problem if the user goes beyond a reasonable number (50?) of pages. To limit the performance impact, this feature should be limited to the UI and not available in the API.

**Problem** MediaWiki's `IndexPager` uses an `offset` URL parameter to determine where the //next// page should start. This strategy is described well in this [[ http://blog.vermorel.com/journal/2015/5/8/nearly-all-web-apis-get-paging-wrong.html | blog post ]]. The strategy has a lot of benefits. Primarily it is [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow | much faster ]] and prevents the user from getting duplicated results as new data is added to the table while they are paginating the results. However, there are some drawbacks. The biggest one is that it only works properly on unique database columns. If the sorting column is non-unique, it shows the user duplicate content, which is the very problem it seeks to solve. During the development of {T236225} it became clear that there is a need to be able to sort a paginated table of data on a non-unique field. **Proposed Solution** Obviously it is better for developers to use the [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/ | seek method ]] whenever possible (and that should be the default). However, MediaWiki, could provide the option of allow sorting on non-unique fields by using the SQL `OFFSET`. This is only a major performance problem if the user goes beyond a reasonable number (50?) of pages. To limit the performance impact, this feature should be limited to the UI and not available in the API.

**Problem** MediaWiki's `IndexPager` uses an `offset` URL parameter to determine where the //next// page should start. This strategy is described well in this [[ http://blog.vermorel.com/journal/2015/5/8/nearly-all-web-apis-get-paging-wrong.html | blog post ]]. The strategy has a lot of benefits. Primarily it is [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow | much faster ]] and prevents the user from getting duplicated results as new data is added to the table while they are paginating the results. However, there are some drawbacks. The biggest one is that it only works properly on unique database columns. If the sorting column is non-unique, it shows the user duplicate content, which is the very problem it seeks to solve. During the development of {T236225} it became clear that there is a need to be able to sort a paginated table of data on a non-unique field. **Proposed Solution** Obviously it is better for developers to use the [[ https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/ | seek method ]] whenever possible (and that should be the default). However, MediaWiki, could provide the option of allow sorting byon non-unique fields by using the SQL `OFFSET`. This is only a major performance problem if the user goes beyond a reasonable number (50?) of pages. To limit the performance impact, this feature should be limited to the UI and not available in the API.