Merge lp:~jtv/launchpad/getBinariesForDomination-bulk into lp:launchpad

Proposed by Jeroen T. Vermeulen
Status: Merged
Approved by: Jeroen T. Vermeulen
Approved revision: no longer in the source branch.
Merged at revision: 14237
Proposed branch: lp:~jtv/launchpad/getBinariesForDomination-bulk
Merge into: lp:launchpad
Prerequisite: lp:~jtv/launchpad/bug-884649-branch-1
Diff against target: 21 lines (+10/-1)
1 file modified
lib/lp/archivepublisher/domination.py (+10/-1)
To merge this branch: bzr merge lp:~jtv/launchpad/getBinariesForDomination-bulk
Reviewer Review Type Date Requested Status
Raphaël Badin (community) Approve
Review via email: mp+81020@code.launchpad.net

This proposal supersedes a proposal from 2011-11-02.

Commit message

Bulk-fetch BinaryPackageReleases in Dominator before sorting.

Description of the change

This is a little side-note to some Dominator optimization work I'm doing for bug 884649: bulk-fetch BinaryPackageReleases when querying for BinaryPackagePublishingHistory records.

There is no functional change, so existing tests apply unchanged.

As far as I can tell, the only performance downside to this is that the query returns more data; nothing else about the query changes, and there should be very little duplication between the extra objects (any duplication only happens, as far as I can see, when a package moves from one component to another or something relatively rare along those lines).

Existing tests:
{{{
./bin/test -vvc lp.archivepublisher.tests.test_dominator
}}}

No lint.

Jeroen

To post a comment you must log in.
Revision history for this message
Raphaël Badin (rvb) wrote :

Looks good.

(Maybe you could use the denormalized attribute on BinaryPackagePublishingHistory to get the relative BinaryPackageNames.)

review: Approve
Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :

Not sure what attribute that is. It's not a matter of getting at the BPNs though, but of bulk-loading them.

Revision history for this message
Raphaël Badin (rvb) wrote :

> Not sure what attribute that is. It's not a matter of getting at the BPNs
> though, but of bulk-loading them.

As discussed on IRC, I was talking about the denormalized attribute BPPH.binarypackagename that stevenK has added recently. It is populated now.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
=== modified file 'lib/lp/archivepublisher/domination.py'
--- lib/lp/archivepublisher/domination.py 2011-11-02 13:36:51 +0000
+++ lib/lp/archivepublisher/domination.py 2011-11-02 13:36:53 +0000
@@ -491,7 +491,16 @@
491 main_clauses.extend(bpph_location_clauses)491 main_clauses.extend(bpph_location_clauses)
492492
493 store = IStore(BinaryPackagePublishingHistory)493 store = IStore(BinaryPackagePublishingHistory)
494 return store.find(BinaryPackagePublishingHistory, *main_clauses)494
495 # We're going to access the BPRs as well. Since we make the
496 # database look them up anyway, and since there won't be many
497 # duplications among them, load them alongside the publications.
498 # We'll also want their BinaryPackageNames, but adding those to
499 # the join would complicate the query.
500 query = store.find(
501 (BinaryPackagePublishingHistory, BinaryPackageRelease),
502 *main_clauses)
503 return DecoratedResultSet(query, itemgetter(0))
495504
496 def dominateBinaries(self, distroseries, pocket):505 def dominateBinaries(self, distroseries, pocket):
497 """Perform domination on binary package publications.506 """Perform domination on binary package publications.