Change Details

Per discussion at T194707#4449342 and elsewhere, the "revision browser" feature is very inefficient and does not scale. First and foremost, it should be using the job queue like all the other queries are. This would involve a UI overhaul of doing everything over AJAX. So you'd load the page, and there'd be text "Loading...", that would be replaced with the data once the queries finish. Currently we get everything with one giant query. This consists of a subquery to get revisions for each individual wiki, UNIONed together, then sorted by timestamp. We could break them out into separate queries, but then you can't sort by timestamp, and LIMIT and OFFSETs for pagination isn't easily achievable. My thoughts are to enforce viewing revisions on a per-wiki basis. So at the top there will be a dropdown of each wiki, and you must select only one.

Per discussion at T194707#4449342 and elsewhere, the Edit List feature is very inefficient and does not scale. First and foremost, it should be using the job queue like all the other queries are. This would involve a UI overhaul of doing everything over AJAX. So you'd load the page, and there'd be text "Loading...", that would be replaced with the data once the queries finish. Currently we get everything with one giant query. This consists of a subquery to get revisions for each individual wiki, UNIONed together, then sorted by timestamp. We could break them out into separate queries, but then you can't sort by timestamp, and LIMIT and OFFSETs for pagination isn't easily achievable. My thoughts are to enforce viewing revisions on a per-wiki basis. So at the top there will be a dropdown of each wiki, and you must select only one.

Per discussion at T194707#4449342 and elsewhere, the "revision browser"Edit List feature is very inefficient and does not scale. First and foremost, it should be using the job queue like all the other queries are. This would involve a UI overhaul of doing everything over AJAX. So you'd load the page, and there'd be text "Loading...", that would be replaced with the data once the queries finish. Currently we get everything with one giant query. This consists of a subquery to get revisions for each individual wiki, UNIONed together, then sorted by timestamp. We could break them out into separate queries, but then you can't sort by timestamp, and LIMIT and OFFSETs for pagination isn't easily achievable. My thoughts are to enforce viewing revisions on a per-wiki basis. So at the top there will be a dropdown of each wiki, and you must select only one.