Last modified: 2008-10-20 17:28:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18021, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16021 - Category pagination (&from and &until) should utilize pageid for disambiguating identical-sortkeys
Category pagination (&from and &until) should utilize pageid for disambiguati...
Status: RESOLVED DUPLICATE of bug 4912
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
1.14.x
All All
: Normal minor (vote)
: ---
Assigned To: Aryeh Gregor (not reading bugmail, please e-mail directly)
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-18 10:26 UTC by Splarka
Modified: 2008-10-20 17:28 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Splarka 2008-10-18 10:26:46 UTC
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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-10-19 18:08:46 UTC
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.).
Comment 2 MZMcBride 2008-10-20 07:42:36 UTC
This bug is likely a duplicate of bug 4912.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-10-20 14:50:16 UTC

*** This bug has been marked as a duplicate of bug 4912 ***
Comment 4 Philippe Verdy 2008-10-20 17:28:14 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links