Merge lp:~deryck/launchpad/fewer-milestone-queries-bugtask-index into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Robert Collins |
Approved revision: | no longer in the source branch. |
Merged at revision: | 11638 |
Proposed branch: | lp:~deryck/launchpad/fewer-milestone-queries-bugtask-index |
Merge into: | lp:launchpad |
Diff against target: |
145 lines (+30/-22) 3 files modified
lib/canonical/widgets/lazrjs.py (+11/-6) lib/lp/bugs/browser/bugtask.py (+12/-4) lib/lp/bugs/browser/tests/test_bugtask.py (+7/-12) |
To merge this branch: | bzr merge lp:~deryck/launchpad/fewer-milestone-queries-bugtask-index |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Approve | ||
Review via email: mp+36458@code.launchpad.net |
Commit message
Reduce the query count for bugtask+index by 2 queries by being a bit smarter about how we get Milestone info.
Description of the change
Inspired by Robert's work related to fixing bug 636158 (timeouts on
bugtask+index), I've been trying to find spots to further reduce the
query count. This is a small branch that fixes up how we get
milestone data for the bug page and reduces the overall query count
for bugtask+index by 2 queries.
It's small, I know, but hey this can land on its own from other work
I'm doing. :-)
To do this, I fixed up the method that looks up the milestones for
the widget and passed in the milestones themselves rather than a
base vocabulary object. I ran a liberal test expression to make
sure this has no fallout:
./bin/test -cvvt "milestone|vocab"
I also lowered the query count in the test Robert added in
TestBugTaskView by 2 queries. To confirm, run:
./bin/test -cvvt TestBugTaskView
The test really only has the one query count change. The rest is me
fixing up lint.
Great, a few thoughts.
safe_hasattr is generally better than hasattr because it swallows less exceptions.
Doing a count() query might be ok if we were to then only read *some* milestones, but as the page shows today, my understanding is we'll always read all milestones - so the change to listify and use len() makes sense to me - but it might be worth a small comment saying that this is what goes on to aid future selves.