Merge lp:~julian-edwards/launchpad/die-buildqueue-die--bug-492632 into lp:launchpad

= Summary =
Make sure buildqueue rows are deleted properly

== Proposed fix ==
Last cycle the buildqueue record was refactored a bit and now it also has an
associated Job and BuildPackageJob.

This fix makes sure that the other two are deleted when
buildqueue.destroySelf() is called.

This is a tentative fix for https://bugs.edge.launchpad.net/soyuz/+bug/492632
since we don't really have a better idea right now.

== Pre-implementation notes ==
Does 4 days of investigative hacking count?

== Implementation details ==
I added a destroySelf() method to the content class which calls the SQLObject
method and deletes the other table rows at the same time.

== Tests ==
bin/test -cvvt testBuildqueueRemoval

== Demo and Q/A ==

= Launchpad lint =

Checking for conflicts. and issues in doctests and templates.
Running jslint, xmllint, pyflakes, and pylint.
Using normal rules.

Linting changed files:
  lib/lp/soyuz/tests/test_build.py
  lib/lp/soyuz/model/buildqueue.py

Looks good. Even if it does not solve the original bug, this code is required for the correct life cycle management of BuildQueue related records going forward.

On Thu, Dec 10, 2009 at 10:50:36AM -0000, Julian Edwards wrote:
> === modified file 'lib/lp/soyuz/tests/test_build.py'
> --- lib/lp/soyuz/tests/test_build.py 2009-07-17 00:26:05 +0000
> +++ lib/lp/soyuz/tests/test_build.py 2009-12-10 10:50:36 +0000

> @@ -43,6 +47,69 @@
>
> return depwait_build
>
> + def assertNoBuildQueue(self, build):
> + """Test there's no buildqueue, buildpackagejob or job for `build`"""
> + store = Store.of(build)
> + result = store.find(
> + BuildPackageJob,
> + BuildPackageJob.build == build.id)
> + bpj_count = result.count()
> + self.assertEqual(
> + bpj_count, 0,
> + "Expected no buildpackagejob rows, got %s" % bpj_count)
> +
> + bpj = result.one()
> +
> + result = store.find(
> + Job,
> + bpj.job == Job.id)
> + job_count = result.count()
> + self.assertEqual(
> + job_count, 0,
> + "Expected no job rows, got %s" % job_count)
> +
> + job = result.one()
> +
> + result = store.find(
> + BuildQueue,
> + BuildQueue.job == job.id)
> + buildqueue_count = result.count()
> + self.assertEqual(
> + buildqueue_count, 0,
> + "Expected no buildqueue rows, got %s" % buildqueue_count)
> +
> + def testBuildqueueRemoval(self):
> + """Test removing buildqueue items.
> +
> + Removing a Buildqueue row should also remove its associated
> + BuildPackageJob and Job rows.
> + """
> + # Create a build in depwait.
> + depwait_build = self._setupSimpleDepwaitContext()
> +
> + # Grab the relevant db records for later comparison.
> + store = Store.of(depwait_build)
> + build_package_job = store.find(
> + BuildPackageJob, depwait_build.id == BuildPackageJob.build).one()
> + job = store.find(Job, Job.id == build_package_job.id).one()
> + build_queue = store.find(
> + BuildQueue, BuildQueue.job == job.id).one()
> +
> + depwait_build.buildqueue_record.destroySelf()
> +
> + # Test that the records above no longer exist in the db.
> + self.assertEqual(
> + store.find(
> + BuildPackageJob,
> + depwait_build.id == BuildPackageJob.build).count(),
> + 0)
> + self.assertEqual(
> + store.find(Job, Job.id == build_package_job.id).count(),
> + 0)
> + self.assertEqual(
> + store.find(BuildQueue, BuildQueue.job == job.id).count(),
> + 0)

Can you be sure that the id attributes are the same, after the objects
have been removed from the db? I'd be a bit wary of using objects that
have been removed from the db. It could be that the attributes get set
to None, for example, no?

--
Björn Tillenius | https://launchpad.net/~bjornt