|Open||None||T28394 Missing Indexes, Inefficient queries and alike (tracking)|
|Open||None||T24744 Add/Update indexes for queries done by the API (tracking)|
|Resolved||Catrope||T16712 API: logevents do not have a namespace filter|
|Resolved||None||T30487 Allow move log to be filtered by namespace of source page and of target page|
|Open||None||T120764 Improve Special:Log|
|Open||None||T16711 Implement a namespace filter for the logging table|
- Mentioned In
- T12331: Introduce page creation log
E181: Code Review Office Hours
T120764: Improve Special:Log
- Mentioned Here
- T73236: Automatically tag edits that make a redirect, or convert a redirected page to a normal page, or move a page across namespaces, etc.
T59084: Store the page_id of the moved page in log_page
T19806: Specific log_action for revision deletions
Note that you can already filter Special:Log by page prefix, which could easily include filtering just by namespace (although it currently doesn't). This functionality is disabled on Wikimedia wikis for performance reasons. I can't recall what the rationale was for that, and no comment explains why $wgMiserMode is used, so I don't know if it would apply to namespace filtering.
Bug 14712 could be related: the list=logevents API module used to have an lenamespace parameter, but I removed it because Aaron Schulz reported the associated database queries were slow.
Thinking about it, I see the reason. You can't use the index for sorting if you retrieve by prefix. It has to either be filesorted, or retrieved from some other index like log_timestamp and filtered. So that won't be able to run acceptably, no, not without another index on (log_namespace, log_timestamp), and you'd have to have all sorts of other tiresome permutations to get namespace filtering to work well in conjunction with others. This is fine to add as an improvement for the page prefix filtering, but it's not going to be able to run on Wikimedia. (Now let me add a comment to that code.)
It's not about "Wikimedia wikis' performance", it's about how indexes work in MySQL. The performance considerations I discuss in comment 3 have not changed in several years and are unlikely to change for the foreseeable future.
(In reply to comment #1)
Note that you can already filter Special:Log by page prefix, which could easily
include filtering just by namespace (although it currently doesn't). This
functionality is disabled on Wikimedia wikis for performance reasons.
Is the ability to filter Special:Log by page prefix still "disabled on Wikimedia wikis for performance reasons"? If so, is the reasoning behind it being disabled still sound? Thanks.
(In reply to comment #7)
(In reply to comment #1)
> Note that you can already filter Special:Log by page prefix, which could easily
> include filtering just by namespace (although it currently doesn't). This
> functionality is disabled on Wikimedia wikis for performance reasons.
Is the ability to filter Special:Log by page prefix still "disabled on
Wikimedia wikis for performance reasons"? If so, is the reasoning behind it
being disabled still sound? Thanks.
Yes and yes, per comment 6
Can we please get some progress on this? you cannot filter per namespace.Try searching for just mainspace deletions.... You cant. Try using the prefix: Template: you dont get template space deletions.
The advanced review log of FlaggedRevs has a namespace filter, see QualityOversight_body.php. It uses what is described as a "cutoff time (mainly for performance)". Looks like it can be adapted for the deletion logs and others, doesn't this solve the performance issue ?
The advanced review log also filters for action type. Doing the same would be useful for other logs, e.g. to sort between deletions, undeletions and selective deletions - see T19806. A general namespace filter for Special:Log wouldn't make sense in my opinion, since many logs aren't tied uniquely to a namespace. Instead, I would suggest an 'advanced log' special page for each of the deletion, protection, block and move logs. This way, each log type would have the most relevant options.
Move is a bit tricky, though, since we need the namespaces for both source and target page. The target title is hardcoded in log_param, so its namespace could be retrieved from there. But what of the namespace of the source page ? We'd better not use the page id, since the page may have been moved again and changed namespace, plus it became the id for the moved page in T59084. I'm not sure which one is returned by log_namespace ?
Every way to examine changes made to the database (edits, deletions, etc.) should be filterable by namespace. Being able to filter Special:Log/delete by namespace is particularly useful for improving the accountability of administrators.