|mediawiki/core : master||Use WatchedItemStore in ApiQueryInfo::getWatchedInfo|
|mediawiki/core : master||Add WatchedItemStore::countVisitingWatchersMultiple|
|mediawiki/core : master||Fix ApiQueryInfo response for prop=watchers|
|mediawiki/core : master||Fix ApiQueryInfo break from use of WatchedItemStore|
|mediawiki/core : master||Add countUnreadNotifications to WatchedItemStore|
|mediawiki/core : master||Move counting of watchers to WatchedItemStore|
|Open||None||T8964 Watch pages for a few days only (add an expiry time)|
|Open||None||T100508 Watchlist expiry: Watch pages for a specified time frame (2013)|
|Open||None||T129478 Refactor watchlist related code to use WatchedItemStore|
|Resolved||Addshore||T129482 Refactor watchlist related API classes to use WatchedItemStore|
|Resolved||WMDE-leszek||T132565 [Task] Refactor database-related code out of ApiQueryWatchlist|
|Resolved||WMDE-leszek||T132566 [Task] Refactor database-related code out of ApiQueryWatchlistRaw|
|Resolved||Addshore||T134387 ApiSetNotificationTimestamp update watchlist wl_notificationtimestamp should use WatchedItemStore|
The API has a very tangled use of the watchlist table (as in it is intertwined with many other things).
This will likely be hard to extract into the Store and may not happen (or may not happen until someone with a better knowledge of the API areas takes a look)
It's not really that tangled. Your confusion mentioned on I2868c31f seems to be because ApiQueryBase uses various methods to manage the building of the $table, $vars, $conds, $options, and $join_conds parameters to be passed to Database::select():
- ApiQueryBase::addTables() appends to $tables.
- ApiQueryBase::addJoinConds() appends to $join_conds.
- ApiQueryBase::addFields() and ApiQueryBase::addFieldsIf() append to $vars.
- ApiQueryBase::addWhere(), ApiQueryBase::addWhereIf(), ApiQueryBase::addWhereField(), ApiQueryBase::addWhereRange(), and ApiQueryBase::addTimestampWhereRange() append to $where.
- ApiQueryBase::addOption(), ApiQueryBase::addWhereRange(), and ApiQueryBase::addTimestampWhereRange() append to $options.
The other bit of difficulty is probably due to the need for batch operations.
As for the modules themselves,
- ApiQueryInfo simply has batch versions of two queries made by InfoAction. You already did one in I5a465773.
- ApiQueryUserInfo is trivial, and you already did it in I91aa1094.
- ApiQueryWatchlist is basically the equivalent of Special:Watchlist, so this is about the same as T129481: Refactor SpecialPages for Watchlist to use WatchedItemStore.
- ApiQueryWatchlistRaw just dumps all the pages on the watchlist, optionally with or filtered by the nullity of the wl_notificationtimestamp field, not terribly different from a read-only version of Special:EditWatchlist/raw, which again is rather related to T129481: Refactor SpecialPages for Watchlist to use WatchedItemStore.