Comment 20 for bug 745799

As previously mentioned, the main area this all goes horribly wrong is in closing bugs for the upload being accepted. OK, in the latest OOPS I posted there are 172 SQL statements and 1.4 seconds before that, which isn't great, but it would be tolerable on its own.

I spent a bit of time trying to make things generally faster, but that requires a much smarter Launchpad developer than I'm capable of playing on TV. The next obvious approach appears to be to add a new ProcessAcceptedBugsJob, which can run as part of the FREQUENT group (contingent on my fix for bug 839659) and which would basically do all the bug.setStatus and bug.newMessage stuff from close_bugs_for_sourcepackagerelease. This would therefore amount to moving the guts of that latter function into a new job, adding job wrapping around it, and changing a few other functions to get bug IDs rather than IBugs (since bug IDs are a bit easier to pass around in job metadata, and the code that got bug objects was unnecessary potato programming anyway). This actually seems quite straightforward. It would require a DB patch as follows to start with:

CREATE TABLE ProcessAcceptedBugsJob (
    id serial PRIMARY KEY,
    job integer REFERENCES Job ON DELETE CASCADE UNIQUE NOT NULL,
    distroseries integer REFERENCES DistroSeries,
    sourcepackagerelease integer REFERENCES SourcePackageRelease NOT NULL,
    json_data text
);

Does that look reasonable in principle?