Last modified: 2014-05-25 05:55:18 UTC
For bots doing large numbers of edits, it's easy to accumulate a huge watchlist. I've received a request for an API method to bulk-clear a watchlist. See also bug 13250 which requests a UI method for this.
Change 132378 had a related patch set uploaded by Brion VIBBER: Add API action=watchlistclear to bulk-clear watchlist. https://gerrit.wikimedia.org/r/132378
a bot can change its preference or set watchlist=nochange to avoid adding a page to the watchlist on each edit. Than there is not a high need of a bulk-clear. But having a bulk-clear on the api side is a valid feature request. It is also possible to add a param to action=watch to avoid a new module.
Try action=watch&unwatch=&token=ABC123&generator=watchlistraw&gwrlimit=max now that action=watch supports generators? ;)
Change 132378 merged by jenkins-bot: Add API action=watch 'entirewatchlist' param to bulk-clear watchlist. https://gerrit.wikimedia.org/r/132378
This should be deployed to WMF wikis with 1.24wmf5, see https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
(In reply to Gerrit Notification Bot from comment #4) > Change 132378 merged by jenkins-bot: > Add API action=watch 'entirewatchlist' param to bulk-clear watchlist. > > https://gerrit.wikimedia.org/r/132378 Looks to have been reverted by <https://gerrit.wikimedia.org/r/133046>. Tentatively re-opening this bug report.
Wondering what the revert means for bug 13250 (UI part).
(In reply to MZMcBride from comment #6) > Looks to have been reverted by <https://gerrit.wikimedia.org/r/133046>. > Tentatively re-opening this bug report. Good move. Comments made on https://gerrit.wikimedia.org/r/#/c/132378/: MaxSem wrote: > The main problem with long watchlist was that at hundreds of thousands members > they got too huge to operate. If you attempt to delete 100k rows from database > in one operation it will cause a replication lag. Springle wrote: > This is only going to come back and bite us. It will cause replag and possibly > also affect row-based replication to labs if the transaction size gets too > large. I note that going to Special:EditWatchlist/raw, blanking the text box, and submitting will perform the same query (calling SpecialEditWatchlist::clearWatchlist() from SpecialEditWatchlist::submitRaw()).
(In reply to Brad Jorsch from comment #8) > I note that going to Special:EditWatchlist/raw, blanking the text box, and > submitting will perform the same query (calling > SpecialEditWatchlist::clearWatchlist() from > SpecialEditWatchlist::submitRaw()). Yeah, however it will happily OOM on really large watchlists, so no harm will be done XD
(In reply to Brad Jorsch from comment #8) > (In reply to MZMcBride from comment #6) > > Looks to have been reverted by <https://gerrit.wikimedia.org/r/133046>. > > Tentatively re-opening this bug report. > > Good move. > > > Comments made on https://gerrit.wikimedia.org/r/#/c/132378/: > > MaxSem wrote: > > The main problem with long watchlist was that at hundreds of thousands members > > they got too huge to operate. If you attempt to delete 100k rows from database > > in one operation it will cause a replication lag. > > Springle wrote: > > This is only going to come back and bite us. It will cause replag and possibly > > also affect row-based replication to labs if the transaction size gets too > > large. > > I note that going to Special:EditWatchlist/raw, blanking the text box, and > submitting will perform the same query (calling > SpecialEditWatchlist::clearWatchlist() from > SpecialEditWatchlist::submitRaw()). problem happens when you're going to Special:EditWatchlist/raw. It is not possible when you dealing with a superhuge list, loading half of million names takes unimaginably long time, but an API request won't take this much (AFAIK) since there is no need to load the old list
Change 135293 had a related patch set uploaded by MaxSem: WIP Add API action=watch 'entirewatchlist' param to bulk-clear watchlist. https://gerrit.wikimedia.org/r/135293
