See T122689#1939440
We need to use ORES in several places but most importantly we need it as prop of revision (rvprop) e.g. in most of cases we query like this and result is like this but if users add "oresscore" to rvprop a new result should have been returned like this. An extra json part:
"oresscore": { "damaging": { "true" : 0.4320, "false": 0.5680 } }Once we agreed on design, implementing them is easy, given that everything is stored in ores_classification table.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Action API integration for ORES | mediawiki/extensions/ORES | master | +730 -10 | |
| API: Add hooks for ApiQueryBase's query and row-processing | mediawiki/core | master | +102 -12 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T143895 [Epic] Implement ORES service proxy in api.php | |||
| Resolved | Anomie | T143614 Introduce ORES rvprop | |||
| Resolved | Anomie | T147939 Add ability to hook into WatchedItemQueryService and ApiQueryWatchlist |
One open question is what to do for revisions that are not already saved in the database:
We might answer the question differently by endpoint, for example list=recentchanges and list=watchlist might return no score (to avoid hundreds of clients all fetching scores for the same just-created revision before the FetchScoreJob runs) while the others fetch.
In the service endpoint 50 is our safest bet, specially on recent change and watchlist because the data probably already stored in redis cache in ores service.
- If there are more than that many revisions that need fetching, is it worth the added complexity of scheduling jobs to hopefully load-and-cache the remaining revisions before the client submits the continuation?
We already have an abstraction layer to trigger jobs of scoring and storing revisions. We can use it.
Although I note FetchScoreJob only does one revision at a time. BTW, what is the 'precache' parameter it passes to ORES in the one case it's currently triggered?
We can work on it and make it accept more than one, I'm guessing it won't be hard.
BTW, what is the 'precache' parameter it passes to ORES in the one case it's currently triggered?
It's for the ORES service to understand source of requests, precache is when the edit is made. So we don't need precache in rvprop or other API modules.
Looking at it closer, it accepts multiple revids for the revid parameter without any issue. Nothing in the job actually depends on being passed only one revid.
Change 313830 had a related patch set uploaded (by Anomie):
API: Add hooks for ApiQueryBase's query and row-processing
Change 313831 had a related patch set uploaded (by Anomie):
Action API integration for ORES
Change 313830 merged by jenkins-bot:
API: Add hooks for ApiQueryBase's query and row-processing