Last modified: 2014-09-24 01:25:45 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 T13739, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11739 - Inverse selection for [[Special:Log]]
Inverse selection for [[Special:Log]]
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: design, patch, patch-reviewed, performance, platformeng
: 35817 (view as bug list)
Depends on:
Blocks: 17293
  Show dependency treegraph
 
Reported: 2007-10-22 18:46 UTC by Erwin
Modified: 2014-09-24 01:25 UTC (History)
12 users (show)

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


Attachments
Proposed patch ; does not print valid titles / headers for now, see comment. (6.69 KB, patch)
2008-03-21 21:18 UTC, Nicolas Dumazet
Details

Description Erwin 2007-10-22 18:46:30 UTC
Please allow for the possibility to inverse select a log type in Special:Log. It would work like inverse namespace selection in Special:RecentChanges, i.e. you would select a type in Special:Log and tick the inverse selection box so that all log actions whose type is not the one specified will be shown. 

For nlwiki most log actions are of the patrol type and the patrol log is imho not as interesting as e.g. the deletion and block log. However the combined log is mostly made up of patrol actions, which makes it difficult to have a look at e.g. all sysop actions.
Comment 1 Nicolas Dumazet 2008-03-21 18:07:56 UTC
I spent a couple of days on this bug.

My first idea was in fact to extend the search to allow a search on multiple types with/without a NOT on the clause.

I wrote it, and... it works. However, as Aaron told me later on, such an extension (even the simpler one, consisting of only allowing a 'NOT' ) restrains the DB, and no optimization on the ORDER BY (needed to sort the result by time) can be performed (see http://dev.mysql.com/doc/refman/5.0/en/order-by-optimization.html). In short, this is not good for DB performance.

http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/ suggests that using UNION (or MINUS in our case) is faster for these kind of requests, but as far as I can tell, that would not allow us to efficiently paginate our result (But please correct me here if I'm wrong.)

I'm changing this to WONTFIX : if some little wiki really need this feature implemented, please contact me : I can easily give out a patch relying on $wgMiserMode to allow this.

Cheers !
Nicolas.
Comment 2 Aaron Schulz 2008-03-21 18:15:07 UTC
This can still be done using the timestamp index, and just using a WHERE on log_type, and avoid a filesort.
Comment 3 Aaron Schulz 2008-03-21 18:19:23 UTC
(In reply to comment #2)
> This can still be done using the timestamp index, and just using a WHERE on
> log_type, and avoid a filesort.
> 

However, this would get very crappy if everything but unused (or little used) logs are set to show.
Comment 4 Nicolas Dumazet 2008-03-21 21:18:34 UTC
Created attachment 4746 [details]
Proposed patch ; does not print valid titles / headers for now, see comment.

Right.
So here is a proposed patch which for now only allows excluding just one log type.

Using FORCE INDEX(times) in this case : No restrictions using $wgMiserMode have been used.

About the page layout, it adds an "invert selection" checkbox next to the type selection drop down menu, leaving the other fields one line below.

Actually missing : the localized messages for the headers and titles of the "all but" logpages. For example, current title for ?title=Special%3ALog&type=patrol&invert=1 is the wrong "patrol log". 
That might require 9 new localized messages 'all-logs-but-TYPE', but there may be a better way to do this : that's why I haven't implemented them yet.

Any comments on the messages ?

Cheers !
Comment 5 Sumana Harihareswara 2011-11-08 15:20:39 UTC
Nicolas, thank you for your patch, and my apologies that it has taken so very long for us to respond to it.  Unfortunately, by now, our codebase has changed so that it no longer applies to the trunk in Subversion.  If you have the time and interest, could you talk about it with MediaWiki developers in the #mediawiki channel in FreeNode (https://www.mediawiki.org/wiki/MediaWiki_on_IRC), and figure out how to revise your patch into something that'll apply?

Thank you!  Again, sorry for the wait.

(Attaching the "reviewed" keyword, and the "design" keyword since this is a UI element.)
Comment 6 Nicolas Dumazet 2011-11-08 19:22:58 UTC
Hello Sumana.

My last commit to Mediawiki was in 2008. I've stopped following development here, and I don't really want to take time getting back into this.

If the feature is interesting, it's probably just as much work to drop my patch, and start over with the current codebase. No hard feelings ;)

Cheers,
Comment 7 Sumana Harihareswara 2012-12-09 17:43:36 UTC
Isarra, you want to take a crack at this?
Comment 8 Sumana Harihareswara 2012-12-09 17:43:41 UTC
*** Bug 35817 has been marked as a duplicate of this bug. ***
Comment 9 Max Semenik 2012-12-16 00:35:27 UTC
-easy, involves DB performance considerations.
Comment 10 Isarra 2012-12-16 01:54:25 UTC
I'm afraid I'm not familiar enough with databases in general or the particular abstractions to adequately approach this.
Comment 11 Andre Klapper 2013-03-11 15:43:54 UTC
Nemo_bis: Is there anything specific here that requires platform engineering input, or why did you set that keyword? To me this looks like a task that a volunteer could start with, see previous patch?
Comment 12 Nemo 2013-03-11 16:47:43 UTC
Per comment 9, it needs performance considerations and any contribution is at risk without; the earlier this bug gets input on how not to melt WMF servers, the better.
Comment 13 Andre Klapper 2013-04-11 13:51:02 UTC
(In reply to comment #12)
> Per comment 9, it needs performance considerations [...]
> the earlier this bug gets input on how not to melt WMF servers, the better.

CC'ing Asher to get input.

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


Navigation
Links