Last modified: 2014-10-03 11:21:24 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.)
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.
Yes, I was thinking on a limit, too, but I wrote too fast, and missed it out ;)
(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.
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. :)
(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.
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.
(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.
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.
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.
Changed component to "RecentChanges"
*** This bug has been marked as a duplicate of bug 470 ***
