nicdumz wrote:

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.

nicdumz wrote:

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 !

Attached:

sumanah wrote:

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-General 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.)

nicdumz wrote:

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,

sumanah wrote:

Isarra, you want to take a crack at this?

sumanah wrote:

*** 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.

Patrol actions are now hidden unless specifically requested (with $wgFilterLogTypes).

Is there any other potential use cases for an inverse log selection that cannot be handled the same way ?

Is there any other potential use cases for an inverse log selection that cannot be handled the same way ?

The original feature request can apply also to seeing log entries not performed by a certain user or not performed on a certain target (for instance deletions not made by FuzzyBot on Translate wikis; or uploads not made by a specific OAuth app on Commons).