Merge lp:~adeuring/launchpad/bug-739052-9 into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Abel Deuring | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 14014 | ||||
Proposed branch: | lp:~adeuring/launchpad/bug-739052-9 | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
332 lines (+145/-25) 6 files modified
lib/canonical/launchpad/webapp/batching.py (+20/-15) lib/canonical/launchpad/webapp/tests/test_batching.py (+38/-0) lib/lp/soyuz/browser/build.py (+19/-2) lib/lp/soyuz/browser/configure.zcml (+1/-1) lib/lp/soyuz/browser/tests/test_build_views.py (+47/-0) lib/lp/soyuz/model/binarypackagebuild.py (+20/-7) |
||||
To merge this branch: | bzr merge lp:~adeuring/launchpad/bug-739052-9 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Approve | ||
Review via email: mp+76241@code.launchpad.net |
Commit message
[r=lifeless][bug=739052] Use StormRangeFactory for the Distribution:
Description of the change
This branch fixes bug 739052: Distribution:
The timeout is the "typical" SQL timeout, which we have more
or less frequently for queries with large resultsets.
The core of the change is that the view for pages like
https:/
to retrieve a batch of the result set, instead of the default
ListRangeFactory.
Working on this core fix, I noticed two problems in StormRangeFactory:
1. StormRangeFacto
ResultSets, only with DecoratedResult
2. StormRangeFacto
that are ordered by more than one column.
Both problems are fixed; I also noticed that StormRangeFactory
had accumulated several lines like
if zope_isinstance
expression = expression.epxr
so I added a helper function plain_expression().
The next change affects the code which generates the ResultSet used
in the view: StormRangeFactory needs result sets where the order
expressions are simple Storm Column instances (or Desc(column).
Things like
resultset.
do not work.
Also, StormRangeFactory works only with Storm result sets, but
not with legacy SQLBase.select() results.
The result set of "our" view is created by
BinaryPackageBu
resultset.
BinaryPackageBu
sort expression was a timestamp.
I was not sure where to add a test for this change: Since the
change is in model code, the test could be added to the tests
of BinaryPackageBuild itself.
On the other hand, the change is _needed_ for browser code, so
the test can also be added to the unit tests of the view class.
I opted for the latter: The test becomes a bit pointless, should
the view class (or some "intermediate code") decide to no longer
call BinaryPackageBu
something-
The test nevertheless makes an assumption about what needs to be
tested: That the sorting depending on the parameter "build status"
but on nothing else.
The last change is a new class DistributionBui
is now registered in ZCML as the view for the +builds page of
IDistribtuions: BuildRecordsView itself is used also for
IDistroArchSeries, and we have four classes for other contexts
that are derived from BuildRecordsView.
If I would have changed BuildRecordsView itself to use
StormRangeFactory, I would have had to check that all five other
contexts return result sets with proper order_by() parameters.
And I know there is at least one method that needs to be changed,
so, to keep the size of the change "within limits", I decided
to define a new class property "range_factory", which is
by default ListRangeFactory, while the new class
DistributionBui
tests:
./bin/test soyuz -vvt test_build_views
\o/ \o/ \o/ \o/