Page MenuHomePhabricator

ProofreadPage internal API queries could use refactoring
Open, Needs TriagePublic

Description

The internal API queries made by ProofreadPage::onInfoAction() and ApiQueryProofread::execute() are hitting the action API "too-many-pageids-for-query" deprecation warning.

For most users,[1] a maximum of 50 IDs may be specified for the pageids parameter. IDs in excess of 50 are ignored with a warning, although someday I'd like to make that an error. Ideally, instead of making internal API queries you'd use PHP code to more directly access the information you require. For ProofreadPage::onInfoAction(), expose your own operation as some business logic class instead of going through ApiMain to get to ApiQueryProofread. For ApiQueryProofread, a well-crafted SQL query would probably be more straightforward.

But if you insist, when you have more than 50 IDs to query you'll need to query them in batches.

[1]: Users with the apihighlimits right have a limit of 500 rather than 50.

Event Timeline

Anomie created this task.Jan 17 2017, 5:20 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 17 2017, 5:20 PM

So rEPRP982494955a71: Chunk page ids in internal API call to avoid too-many-pageids-for-query fixed the ApiQueryProofread issue, but onInfoAction still needs updating AIUI?

I think I was mistaken about onInfoAction hitting the warning, it looks like that function only ever passes one pageid.

While the cleanup suggested in the task description would still be a good idea, I think the too-many-pageids-for-query issue is fixed with rEPRP982494955a71: Chunk page ids in internal API call to avoid too-many-pageids-for-query.

Anomie renamed this task from ProofreadPage internal API queries are hitting API too-many-pageids-for-query deprecation warning to ProofreadPage internal API queries could use refactoring.Jun 5 2017, 8:03 PM