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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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