Last modified: 2014-10-08 00:55:23 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 T73767, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71767 - Result count < limit with list=allusers&auprop=groups|rights
Result count < limit with list=allusers&auprop=groups|rights
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.24rc
All All
: Unprioritized minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-07 23:02 UTC by Robert Morley
Modified: 2014-10-08 00:55 UTC (History)
5 users (show)

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


Attachments

Description Robert Morley 2014-10-07 23:02:09 UTC
With either the groups or rights properties requested, the total number of users returned can be less than the limit requested based somewhat indirectly on the number of explicit groups returned in the result set.

Example: http://en.wikipedia.org/w/api.php?action=query&list=allusers&aufrom=A&auprop=groups&aulimit=2

I believe the problem comes from the fact that $count is updated per row rather than per user. Moving the count inside the first if block might be sufficient, but a full re-write that issues a second query for groups/rights would probably simplify the coding drastically. The former, I can do myself; the latter, my PHP skills aren't up to, so I'm putting this out there in case a better programmer than me wants to take it up. :)
Comment 1 Brad Jorsch 2014-10-08 00:35:32 UTC
The API is explicitly allowed to return fewer than the requested limit. In certain extreme cases it may even return zero results but still include a continuation value.
Comment 2 Robert Morley 2014-10-08 00:38:19 UTC
Just because it's allowed to return fewer results than requested doesn't mean this is good coding. I'll grant that it's working close to what's expected, so it's not a high priority, but it's still a bug.
Comment 3 Brad Jorsch 2014-10-08 00:43:24 UTC
OTOH, making several queries rather than one is not often very good from a performance perspective, which is why it's not done.

This particular example may or may not be affected by Gerrit change #163596, which is being deployed to WMF wikis with 1.25wmf2 (see https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule; enwiki is still on 1.25wmf1).
Comment 4 Robert Morley 2014-10-08 00:55:23 UTC
I only glanced at it, but your updated code looks like it'll resolve both the problem I reported and another one (with $sqlLimit) that I noticed just after I posted.

As far as the approach goes, I understand the potential performance hit. (I was a DBA for most of my career.) On the flip side, though, returning a cross-join with a lot of duplicated data can also incur a performance hit, so depending on the database internals, it might well be less expensive to do two queries, particularly when the explicit groups query is likely to be very small.

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


Navigation
Links