r88025 MediaWiki - Code Review archive

This is a really great regression for authors's usability. Please add an index before this revision goes live on WMF

This isn't really indexable.

A bad regression indeed. Is there no way this could be implemented in another way? Is the current code too inefficient even for small wikis?

Marking OK. The code is fine, it is better to remove the NS filtering than making the whole project slow.

You can allow namespace filter, when the recentchanges table is in the query, than only the last few days are filterable for namespaces, but better than nothing. That filter is already on Special:RecentChanges, so there should be no problem. Thanks.

Eh, so miser mode is enforced in UI, but it still can be overridden with a URL parameter?

Fixed in r88026

The system is slower and the "contributions page filtered for namespace or RevisionDeleted edits" removal is a drama. I use that hundred times per day.

+1 Unable to filter user contributions by namespace is really painfully.

It is terrible change. Maybe it may be better to limit checking only 100 edits of user with default settings and option to fetch more?

There is no way to express that in SQL. Could be done on the client side, though.

Ahm and by 'client side' I meant PHP :)

Wtf? Please undo this "improvement" immediately... -_-

Please read the given comments and discussion. The query to fetch contributions by namespace is not indexed on misermode-wikis, thus this query will not be allowed on those wikis.

That's not good enough. This was a feature in use by countless people and extremely helpful.

Tough?

Go have a read https://bugzilla.wikimedia.org/show_bug.cgi?id=31197

? Sorry, I don't understand anything of your technical terms...

This function worked for many years quite fine thus I don't see any reason to take away this feature from us (what's actually the problem? too much performance needed by these filters?). Most of the Wikipedians need this function strongly. What about first thinking about the consequences before just tinkering with the software? Introducing senseless and precarious image filters is obviously no problem but a widely used function that worked fine for many years is? Hmm...

(Please excuse my strong language but this is the icing on the cake of an already arduous day...)

If you're already having a bad day I won't add to it with an aggressive reply, but suffice to say that you're correct in your estimation: implementing this filter requires too many server resources. Domas, who apparently requested this change, is our most experienced database 'guru'; if he says something is wrong, it's usually because it is.

that's *not nearly* good enough. there would have been many ways to limit db resource occupation without subverting usability to *that* degree. just taken from bugzilla 31197, e.g.: A)

look over last n edits
kill query after 10 seconds
cache results

B)

disable for users where
subject user_editcount is 100,000 or more, and 
invokers don't have a new permission like noquerylimit (similar to noratelimit)
which would be given to administrators and maybe rollbackers

and there would be lots more.

• do* also consider lots of already posted arguments countering your replies, e.g.

Users need this (finding edits in specific namespaces), therefore if you don't allow this feature they'll just load the 
complete list of edits, 5000 at a time, and search the namespace within the pages. In your example: 
Rambot, 140 000 edits, 28 pages; for the first I got "Served by mw30 in 14.588 secs", this makes a total of almost 7 minutes."

i strongly oppose the way such "fixes" are brought up without prior discussion with the people actually maintaining wp and expect a quick solution!

Definitely not a good move - please restore the functionality, or revert back to previous version (which would solve all the other bugs that seem to have been introduced - see WP:VPT on enwiki).