Merge lp:~adeuring/launchpad/bug-594247 into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Gavin Panella |
Approved revision: | no longer in the source branch. |
Merged at revision: | 11933 |
Proposed branch: | lp:~adeuring/launchpad/bug-594247 |
Merge into: | lp:launchpad |
Diff against target: |
495 lines (+233/-121) 2 files modified
lib/lp/bugs/model/bugtask.py (+166/-117) lib/lp/bugs/tests/test_bugtask_search.py (+67/-4) |
To merge this branch: | bzr merge lp:~adeuring/launchpad/bug-594247 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | code | Approve | |
Graham Binns (community) | code | Approve | |
Review via email: mp+40713@code.launchpad.net |
Commit message
[r=allenap,
Description of the change
This branch fixes bug 594247: searchTasks with structural_
times out regularly.
The fix uses stub's suggestion from a comment in the bug report
to (LEFT) JOIN the tables Product and StructuralSubsc
to define the filter clause "StructuralSubs
directly in the main query.
This required some larger modification of the method
BugTaskSet.
query, clauseTables, orderby_arg, decorator. query contains a string
with the WHERE clause, clauseTables contains a list of tables
used in the WHERE clause.
Simply adding Storm Join instances for
LEFT OUTER JOIN Product ON BugTask.
and
JOIN StructuralSubsc
to clauseTables has at least one problem: The method BugTaskSet.search()
optionally joins some tables, including Product, in order to pre-load
some objects that will be needed later to process a request.
So it could happen that the table Product is JOINed twice: The first time
in clauseTables because it is needed in the WHERE expression for
structural subscription, the second time to pre-load Storm Product
instances.
Hence I did not add the Storm Join instances to clauseTables; instead,
BugTaskSet.
which contains a sequence of tuples (storm_table, join_expression).
A new method BugTaskSet.
clauseTables together with a sequence of Join instances needed to
pre-load Product, Bug, SourcePackageName instances, so that each
table appears exactly once in the WHERE clause of the SQL query.
The new way to find bugtasks related to a structural subscription
can return bug tasks twice, for example, if somebody has
a structural subscription to a distribution and to a distro source
package. So BugTaskSet.
has_duplicate_
BugTaskSet.
by BugTaskSet.
buildQuery() became a bit more complicated, and BugTaskSet.search()
could already create two variants of the SQL query: one to retrieve
only BugTask instances and another to retrieve related Product,
Bug, SourcePackageName instances. We can consider searchBugIds()
to be variant of search() which just defines another type of data to
retrieve, so the SQL query is now built in a new method _search()
which is called by search() and by searchBugIds().
This required another tweak: BugTaskSet.
decorator for the result set whichs avoids later SQL queries
ensuring that the current user is allowed to view a bug. (see
lp.bugs.
This decorator assumes that the Storm query returns BugTask
instances, which is not the case for BugTaskSet.
So BugTaskSet.
If it is True, _search() returns a plain Storm result set,
otherwise, it returns a DecoratedResultSet.
Treatment of queries which may have duplicate result rows
("if has_duplicate_
call resultset.
for one bugtask if somebody is subscribed to a distribution and
to a distro source package and if we preload SourcePackageName.
Using a DISTINCT ON BugTask.id query would require sorting by
BugTask.id, so I simply used a sub-query.
The part of BugTaskSet.search() (now in _search()) which handles
queries with more that one BugTaskSearchParams instance now
preloads/prejoins Bug, Product etc only if _noprejoins is False.
Finally, I added some more tests to test_bugtask_
no lint.
test: ./bin/test -vvt test_bugtask_search
It might make sense to change BugTaskSet.
in a follow-up brnach so that it calls _search() directly,
instead of calling search(), extracting milestone IDs
from the result set and running another SQL query to retrieve
these milestones.
Hi Abel,
As we discussed on IRC, I think you should get a review from someone more SQL / Storm savvy than I, since my brain seems to just skip off those parts of the code.
I'm happy with the rest of the diff, with just two comments:
> 94 + # Circular.
Please expand this to something less terse ;). ("Prevent circular
import problems." or something similar.)
> 319 + # Circular.
Here too.