Last modified: 2008-12-14 07:10:56 UTC
I've tried to introduce paging for file histories in the API, but found that it's not implemented in the UI either (it should). This seems to be because the code in File.php is very pager-unfriendly: file histories are gotten by calling File::nextHistoryLine() repeatedly, and there is no way to specify an offset at which to start. If that is possible, paging can be implemented. Notice: the reason I think paging should be implemented is that vandals could upload thousands of different versions of an image, flooding the image history in both the UI and the API and potentially mounting a DoS attack (hence the high severity). I've limited the API to 500 file revisions as a temporary measure, and I suggest someone do the same with the UI.
News flash: I looked at the LocalFile::nextHistoryLine() and it turns out to do a DB query on every call. As that function is typically called in a loop, that means DB queries in loops (waits for Domas to kill someone).
Introduced new method in r29966
(In reply to comment #1) > News flash: I looked at the LocalFile::nextHistoryLine() and it turns out to do > a DB query on every call. As that function is typically called in a loop, that > means DB queries in loops (waits for Domas to kill someone). > ImagePage.php doesn't use that though. It does the old versions in one query and iterates using it's own wrapper so to speak. Does anything use nextHistoryLine() though?
Done in r44564 using getHistory()
