Last modified: 2014-10-03 11:21:24 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 T18402, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16402 - Contribution list for multiple users
Contribution list for multiple users
Status: RESOLVED DUPLICATE of bug 470
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.14.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-20 19:56 UTC by Daniel Tar
Modified: 2014-10-03 11:21 UTC (History)
4 users (show)

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


Attachments

Description Daniel Tar 2008-11-20 19:56:59 UTC
It would be great aid in following edit wars if we would have an opinion to enter multiple usernames to Special:Contributions. A solution would be to allow entering multiple usernames separated with | (or an other character not enabled in usernames). If it's not a good idea, we should create an other special page dedicated to this feature (as we can't apply custom whitelist/blacklist filter to the Special:RecentChanges.)
Comment 1 Brion Vibber 2008-11-20 20:08:32 UTC
We don't currently support it since it's not a super efficient query... but in theory, combining multiples into a single list should be no worse than doing a query on each one separately -- we'd just interleave the results and throw away anything past the paging limit. Probably not super hard to do, as long as there's a reasonable limit on how many users to query.
Comment 2 Daniel Tar 2008-11-20 20:10:22 UTC
Yes, I was thinking on a limit, too, but I wrote too fast, and missed it out ;)
Comment 3 Roan Kattouw 2008-11-20 22:13:45 UTC
(In reply to comment #1)
> we'd just interleave the results and throw away
> anything past the paging limit.

My gut tells me paging that properly (i.e. making the (next 50) links work right) would be really awkward. I don't really feel like thinking it through at this hour (someone should, though), but I think making this page right would be a real pain in the ass.
Comment 4 Brion Vibber 2008-11-20 22:17:47 UTC
I don't think it'd be that awkward at all; you just take whichever timestamp is the first one that fell off the list. :)
Comment 5 Roan Kattouw 2008-11-20 22:21:28 UTC
(In reply to comment #4)
> I don't think it'd be that awkward at all; you just take whichever timestamp is
> the first one that fell off the list. :)
> 

Yeah, that would work. But it wouldn't be an efficient query AFAIK, since you're doing a range scan on something else than the ORDER BY.
Comment 6 Brion Vibber 2008-11-20 22:27:32 UTC
Right, I was thinking it might well be best to actually do multiple queries if the DB won't do it cleanly on its own -- each one follows a clean index. Kind of icky, but not hugely expensive... if people were going to load several contribs pages anyway, we're doing the same queries.
Comment 7 Roan Kattouw 2008-11-20 22:38:55 UTC
(In reply to comment #6)
> Right, I was thinking it might well be best to actually do multiple queries if
> the DB won't do it cleanly on its own -- each one follows a clean index. Kind
> of icky, but not hugely expensive... if people were going to load several
> contribs pages anyway, we're doing the same queries.
> 

Oh, of course, you're doing one query per user, so all the individual queries sort by timestamp with a range scan on timestamp. That'll work just fine of course. The only problems left IMO are that the queries in loops thing is ugly (Domas probably won't like it) and that you're requesting and processing way more DB rows than you're actually gonna use.
Comment 8 Brion Vibber 2008-11-20 22:40:36 UTC
It's moderately ugly, but I can't think of a better way to do it. :) The individual queries are cheap, and as long as we enforce a low limit it'll be cheaper to do those queries in-wiki than have people load 5 separate pages.
Comment 9 Splarka 2008-11-21 02:08:28 UTC
As an experiment in insanity here is a gadget (max 500 results, ~5 users, no continue)
 http://en.wikipedia.org/wiki/User:Splarka/contribsmulti.js

Screenshot:
 http://img141.imageshack.us/img141/5771/multifp0.gif

It fetches each user's last 500 contribs via the API, stuffs them all into an array, sorts them, and then outputs 500 (max). If it output more it might miss some.
Comment 10 Siebrand Mazeland 2009-02-02 13:32:38 UTC
Changed component to "RecentChanges"
Comment 11 Chad H. 2009-07-16 17:43:03 UTC

*** This bug has been marked as a duplicate of bug 470 ***

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


Navigation
Links