Last modified: 2012-01-01 22:58:05 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 T35455, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33455 - Special:WantedFiles is limited to 1000 files total (not just per page)
Special:WantedFiles is limited to 1000 files total (not just per page)
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.20.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-01 12:17 UTC by Gregor Hagedorn
Modified: 2012-01-01 22:58 UTC (History)
3 users (show)

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


Attachments

Description Gregor Hagedorn 2012-01-01 12:17:21 UTC
I don't believe this:

http://en.wikipedia.org/w/index.php?title=Special:WantedFiles&limit=500&offset=1000

which claims "There are no results for this report."

:-)

http://en.wikipedia.org/w/index.php?title=Special:WantedFiles&limit=500&offset=500 works ok.

It seems that 1000 is presently not the max for the browsing page size (how many on one page) but for the total number of results. Since all files shown are false positives (i.e. files wanted only locally, but present on Commons), wanted files currently claims the English Wikipedia uses only 1000 files from Commons.
Comment 1 Bawolff (Brian Wolff) 2012-01-01 12:21:41 UTC
This is because those pages take a long time to generate, so what we do is store the top 1000 (or something) results, and save them. Thus we only have the first 1000 results stored. That's pretty unlikely to change (although we could potentially change the message to make it more clear somehow what is actually going on).
Comment 2 Gregor Hagedorn 2012-01-01 12:28:14 UTC
I did not realize this. But we agree that this makes WantedFiles completely unusable?

I understand that the queries are expensive. I also guess that mediawiki, due to its excellent page caching has no mechanism for caching database query results, correct? Such consistency queries could, from a user standpoint, easily be updated only once a day, but then fully. Provided it is shown transparently how old the results are. But I understand that this would need a new infrastructure.
Comment 3 Bawolff (Brian Wolff) 2012-01-01 12:36:37 UTC
(In reply to comment #2)
> I did not realize this. But we agree that this makes WantedFiles completely
> unusable?

Heck, just the sheer number of false positives make it totally useless

> 
> I understand that the queries are expensive. I also guess that mediawiki, due
> to its excellent page caching has no mechanism for caching database query
> results, correct? Such consistency queries could, from a user standpoint,
> easily be updated only once a day, but then fully. Provided it is shown
> transparently how old the results are. But I understand that this would need a
> new infrastructure.

We actually do cache the queries and not just the output on to the page (in the querycache table). The total number of results cached is controlled by [[mw:manual:$wgQueryCacheLimit]]. Special:wantedfiles should also have the line on it:

The following information is cached, and was last updated 16:04, 31 December 2011. 

To indicate how outdated the info is.
Comment 4 Gregor Hagedorn 2012-01-01 12:59:54 UTC
OK. I better understand now why the solution to just browse through (and hide the false positives) does not work. Thanks for your patience!
Comment 5 Krinkle 2012-01-01 22:58:05 UTC
It does, on top it says:


"The following information is cached, and was last updated 14:37, 1 January 2012."

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


Navigation
Links