Comment 1 for bug 831699

Revision history for this message
Martin Pool (mbp) wrote :

There's not, at the moment, any obvious table of "successful import", in the way there is one for failures, so we could possibly infer this from other tables, or perhaps just add it as a new table. When the job succeeds (in `finish_job`) we delete the job and the failure record, and we don't obviously create anything else.

So I think we should either add a 'success' table, or refactor the current `failure` into being something like an `outcomes` record that could be either success or failure.

Also, in there, this code seems strange:

    def finish_job(self, package, job_id, success, output):
        c = self.conn.cursor()
        try:
            now = datetime.datetime.utcnow()
            if job_id > 0:
                row = c.execute(self.JOBS_TABLE_SELECT_JOB,
                                (job_id,)).fetchone()
                if row is not None:
                    c.execute(self.JOBS_TABLE_UPDATE,
                            (row[1], 0, row[3], row[4], row[5], now, row[0]))
            if success:
                row = c.execute(self.FAILURES_TABLE_FIND, (package,)).fetchone()
                if row is not None:
                    c.execute('delete from %s where package=?'
                            % self.JOBS_TABLE, (package,))
                c.execute(self.FAILURES_TABLE_DELETE, (package,))
                c.execute(self.OLD_FAILURES_TABLE_DELETE, (package,))
            else:
                self._set_failure(c, package, output, now)
            self.conn.commit()

I wonder what the logic is behind deleting the job if there was previously a failure record.