Last modified: 2008-04-02 16:31:59 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 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