Last modified: 2011-12-06 21:55: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 T20770, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18770 - listing of unprotected page with list=allpages
listing of unprotected page with list=allpages
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-11 17:20 UTC by Umherirrender
Modified: 2011-12-06 21:55 UTC (History)
4 users (show)

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


Attachments

Description Umherirrender 2009-05-11 17:20:23 UTC
There is no way to get only none protected page with the api.
Maybe add a 'none' to 'apprlevel' to allow listing of this page.
Thanks.
Comment 1 Bryan Tong Minh 2009-07-12 20:05:56 UTC
Not really trivial to accomplish this. LEFT JOIN against page_restrictions?
Comment 2 Sam Reed (reedy) 2010-01-06 23:29:16 UTC
Left join the restriction table.. Then only output the page if some restriction col is null for that row?
Comment 3 Sam Reed (reedy) 2010-01-11 13:24:04 UTC
[13:20:06] <RoanKattouw> OK so about the unprotected pages in list=allpages thing
[13:20:19] <RoanKattouw> The LEFT JOIN approach you and Bryan came up with is the right one
[13:21:00] <RoanKattouw> I'm not 100% sure about its efficiency and scalability to Wikimedia levels, but I think it should be OK because protected pages are scarce
Comment 4 Sam Reed (reedy) 2010-01-11 14:15:12 UTC
[13:35:33] <RoanKattouw> domas: Are queries like these OK to run on the cluster? http://pastebin.com/m72223c4b
[13:35:43] <RoanKattouw> EXPLAIN says "using where" but I think it's lying
[13:36:29] <domas> depends
[13:36:35] <RoanKattouw> Also the row count is huge but I don't believe it'll really examine that much rows for a query with WHERE foo=const ORDER BY bar LIMIT 51 when there's an index on (foo,bar)
[13:36:42] <RoanKattouw> *many
[13:36:48] <domas> if all pages have restrictions, this gets really expensive 
[13:36:49] <domas> :)
[13:36:53] <Reedy> heh
[13:37:01] <RoanKattouw> Yeah it was kinda based on the assumption that protected pages are scarce
[13:37:29] <RoanKattouw> Of course the "get pages with protection X" variant (which already runs on the cluster) joins the tables in reverse order
[13:37:56] <RoanKattouw> ... hopefully
[13:37:59] RoanKattouw checks
[13:41:15] <RoanKattouw> Hm the "get pages with protection X" query does indeed join page_restrictions first at the cost of filesorting, but I guess that's the lesser of two evils unless I totally rewrite this module to page by page ID
Comment 5 Sam Reed (reedy) 2010-01-11 14:28:33 UTC
[14:18:32] <RoanKattouw> Reedy: Short summary: given that the existing appr* queries are apparently OK, this one should not be a problem

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


Navigation
Links