Launchpad itself

Merge lp://staging/~julian-edwards/launchpad/count-cull into lp://staging/launchpad

count-cull
Merge into devel

Proposed by Julian Edwards on 2011-01-13

Status:

Merged

Approved by:

Robert Collins on 2011-01-13

Approved revision:

no longer in the source branch.

Merged at revision:

12203

Proposed branch:

lp://staging/~julian-edwards/launchpad/count-cull

Merge into:

lp://staging/launchpad

Diff against target:

379 lines (+60/-66)

13 files modified

lib/lp/soyuz/adapters/archivedependencies.py (+3/-5)
lib/lp/soyuz/browser/archive.py (+8/-14)
lib/lp/soyuz/browser/build.py (+1/-1)
lib/lp/soyuz/model/archive.py (+1/-1)
lib/lp/soyuz/model/archivepermission.py (+16/-13)
lib/lp/soyuz/model/binarypackagebuild.py (+2/-2)
lib/lp/soyuz/model/distroseriessourcepackagerelease.py (+3/-2)
lib/lp/soyuz/model/publishing.py (+4/-4)
lib/lp/soyuz/model/queue.py (+9/-8)
lib/lp/soyuz/scripts/initialise_distroseries.py (+9/-9)
lib/lp/soyuz/scripts/packagecopier.py (+2/-2)
lib/lp/soyuz/scripts/ppa_add_missing_builds.py (+1/-1)
lib/lp/soyuz/scripts/publishdistro.py (+1/-4)

To merge this branch:

bzr merge lp://staging/~julian-edwards/launchpad/count-cull

High

Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Robert Collins (community)		2011-01-13	Approve on 2011-01-13
Review via email: mp+46158@code.staging.launchpad.net

Commit message

Cull a load of unnecessary .count()s in favour of less-expensive SQL.

Description of the change

= Summary =
Cull a load of unnecessary .count()s in favour of less-expensive SQL.

== Proposed fix ==
See bug 701947

== Implementation details ==
See bug 701947

I had trouble converting one of them as you can see from the comment, I filed
bug 702425 about it.

== Demo and Q/A ==
n/a

Revision history for this message

Robert Collins (lifeless) wrote on 2011-01-13:

To confirm I grok this: rather than forcing a complete evaluation, we do a LIMIT 1 query? Sounds reasonable to me.

review: Approve

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2011-01-13:

On Thursday 13 January 2011 20:39:08 you wrote:
> Review: Approve
> To confirm I grok this: rather than forcing a complete evaluation, we do a
> LIMIT 1 query? Sounds reasonable to me.

Yup, that's what is_empty() does, which is what __nonzero__ calls. I've also
avoided double queries in places by just trying to access the data and
catching IndexError.

Revision history for this message

Robert Collins (lifeless) wrote on 2011-01-13:

Great. Note that it won't be any faster *unless* we're able to issue
the result from an index, *or* its unsorted.

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2011-01-13:

On Thursday 13 January 2011 22:04:39 you wrote:
> Great. Note that it won't be any faster *unless* we're able to issue
> the result from an index, *or* its unsorted.

Well in the cases where it checks to see if something has a count before
accessing results[0] I'd say that's an easy win :)