Merge lp:~adeuring/lazr.batchnavigator/lazr.batchnavigator-result-length-from-range-factory into lp:lazr.batchnavigator
Status: | Merged |
---|---|
Approved by: | Aaron Bentley |
Approved revision: | 51 |
Merged at revision: | 51 |
Proposed branch: | lp:~adeuring/lazr.batchnavigator/lazr.batchnavigator-result-length-from-range-factory |
Merge into: | lp:lazr.batchnavigator |
Diff against target: | 0 lines |
To merge this branch: | bzr merge lp:~adeuring/lazr.batchnavigator/lazr.batchnavigator-result-length-from-range-factory |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Aaron Bentley (community) | Approve | ||
Review via email: mp+74459@code.launchpad.net |
Description of the change
This branch is another (hopefully the last...) step to prepare lazr.batchnavigator for usage in combination with StormRangeFactory.
One time out problem are the SELECT count(*) queries we need in batched views, just to show a text like "10 -> 19 of 1209 results" in a batched view.
lifeless suggested to use "EXPLAIN SELECT..." instead; the result is not necessarily precise but should be "good enough" as an indicator. Some older revisions of lazr.batchnavigator already make sure that the length of the result set is not used for any other purpose in lazr.batchnavig
The class _Batch has a cached property listlength, which calls either len(resultset) or len(IFiniteSequ
The core of this branch is simply to let _Batch.list_length retrieve the length of the resultset from its range factory: IRangeFactories already handle all other access to a resultset for _Batch, and they are supposed to "know best" how to access the result set efficiently.
Aside from some typos discussed on IRC, this is good to land. You may wish to change the result_length member to "rough_length" or "approx_length".