Last modified: 2014-09-24 01:25:45 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.
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.
This can still be done using the timestamp index, and just using a WHERE on log_type, and avoid a filesort.
(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.
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 !
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.)
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,
Isarra, you want to take a crack at this?
*** Bug 35817 has been marked as a duplicate of this bug. ***
-easy, involves DB performance considerations.
I'm afraid I'm not familiar enough with databases in general or the particular abstractions to adequately approach this.
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?
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.
(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.
