Last modified: 2008-04-02 16:31:59 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 T12524, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10524 - Special:Log displays only the most recent 15 000 items in Arabic Wikipedia
Special:Log displays only the most recent 15 000 items in Arabic Wikipedia
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 5446
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-10 12:02 UTC by Meno25
Modified: 2008-04-02 16:31 UTC (History)
1 user (show)

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


Attachments

Description Meno25 2007-07-10 12:02:18 UTC
In Arabic Wikipedia, Special:Log displays only the most recent 15 000 items. When clicking next again the same items are displayed again. This is true for deletion log and user creation log (the only 2 logs which have more than 15 000 items). For example deletions in arwiki older than February 2007 are not displayed. I have noticed this also in English Wikipedia in the upload log (didn't try other logs).
Comment 1 Raimond Spekking 2007-07-10 12:21:23 UTC
The limit is 10 000 items, defined in SpecialLog.php for all wikis running with $miserMode=true for server healthy, especially all Wikimedia wikis.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-10 21:37:02 UTC
This is due to bug 5446.  If that were fixed this would be a non-issue.
Comment 3 Aaron Schulz 2007-07-10 21:40:11 UTC
Well, when log_id is added, we can use pager to go throw then on and index, so this restriction won't be necessary forever.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-10 22:43:38 UTC
True, you could use ID offsets instead, but that assumes IDs are in strict chronological order, which in principle they may not be (if for some reason, e.g., multiple wiki databases are merged).  Besides, IDs are meaningless, so date would be a much better paging criterion in terms of utility for external tools or hand-editing of URLs.  I'd avoid ID offsets.  We even have the necessary indices for date sorting already, which we don't yet for ID, although presumably we will soon.
Comment 5 Aaron Schulz 2007-07-10 23:19:16 UTC
(In reply to comment #4)
> True, you could use ID offsets instead, but that assumes IDs are in strict
> chronological order, which in principle they may not be (if for some reason,
> e.g., multiple wiki databases are merged).  Besides, IDs are meaningless, so
> date would be a much better paging criterion in terms of utility for external
> tools or hand-editing of URLs.  I'd avoid ID offsets.  We even have the
> necessary indices for date sorting already, which we don't yet for ID, although
> presumably we will soon.
> 

True. Date sorting is fine. I'd be ok with either.
Comment 6 Aaron Schulz 2008-04-02 16:31:59 UTC
Logs use pager as of r32685.

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


Navigation
Links