Page MenuHomePhabricator

Category pagination (&from and &until) should utilize pageid for disambiguating identical-sortkeys
Closed, ResolvedPublic

Description

Author: herd

Description:
Categories sort by sortkey, but if there are more than $wgCategoryPagingLimit pages with the same sortkey, you cannot continue with &from/&until. A less critical flaw is occasional imperfect pagination if a few pages have matching sortkeys. The API solves this by using Sortkey|articleID (-> cl_from). The UI version should probably do the same thing.

Note that Sortkeys can contain pipes, so simply utilizing the pipe character as the API does is not the best of ideas (it involves exact sortkey matching, while the from/until use >= or <= string comparison). However, using two parameters is not easy, as IndexPager only supports paging by one field.

Slightly related is: bug 16017

Bug found by: carl-m, Simetrical. Resolution proposed by: RoanKattouw. Transcription monkey: Splarka.


Version: 1.14.x
Severity: minor

Details

Reference
bz16021

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:20 PM
bzimport set Reference to bz16021.

ayg wrote:

Assigning to self.

(In reply to comment #0)

Note that Sortkeys can contain pipes, so simply utilizing the pipe character as
the API does is not the best of ideas (it involves exact sortkey matching,
while the from/until use >= or <= string comparison).

It should just be a separate URL parameter. We could use "]" or newline or something, which can't currently be in sortkeys; or an unprintable character. But a separate parameter is simpler and cleaner and more future-proof.

However, using two
parameters is not easy, as IndexPager only supports paging by one field.

Right, now I remember that. This all came up with allowing sorting by count on [[Special:Categories]] (see various commits to Pager.php, r32198 ff.).

This bug is likely a duplicate of bug 4912.

ayg wrote:

*** This bug has been marked as a duplicate of bug 4912 ***

I also support the better idea of inserting the unique id outside of the sort key, in a distinct parameter. Currently, keys get truncated (when too long) and "UNIQUE" is followed by some id, but this is really not clean and breaks the natural order. In addition, it would save space in the index (because the unique id could be a simple numeric field instead of a string).
Just "sort by key,id" in your SQL, and make sure that the "previous/next 200" links specify the id to make them work correctly.