Merge lp:~james-w/lazr.restfulclient/improve-collection-fetch-optimisation into lp:lazr.restfulclient
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~james-w/lazr.restfulclient/improve-collection-fetch-optimisation |
| Merge into: | lp:lazr.restfulclient |
| Diff against target: |
39 lines (+12/-10) 1 file modified
src/lazr/restfulclient/resource.py (+12/-10) |
| To merge this branch: | bzr merge lp:~james-w/lazr.restfulclient/improve-collection-fetch-optimisation |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Graham Binns (community) | code | 2010-01-05 | Needs Information on 2011-01-25 |
|
Review via email:
|
|||
| James Westby (james-w) wrote : | # |
| James Westby (james-w) wrote : | # |
Actually this doesn't allow you to limit the page size
all the time. Once you get beyond the first page it
makes a request with no size specified.
In order to do this properly we would either need a
max-size request variable, would that be feasible for
LP?
Thanks,
James
| Graham Binns (gmb) wrote : | # |
Hi James,
Thanks for this branch. A couple of things:
1. I don't see any tests for this change. Are there tests that already cover this functionality? If so, how will this change affect them? If not, can you add some?
2. Formatting multi-line conditionals is always a bit weird. We usually wrap after the first 'and' or 'or'. I've written a patch that fixes this for this branch: http://
> Actually this doesn't allow you to limit the page size
> all the time. Once you get beyond the first page it
> makes a request with no size specified.
>
> In order to do this properly we would either need a
> max-size request variable, would that be feasible for
> LP?
>
3. I don't really understand what you mean here (I'm still jetlagged, which doesn't help). Can you explain it further (possibly using words of no more than one syllable)?
Unmerged revisions
- 87. By James Westby on 2010-01-05
-
Account for the case where there isn't a first page properly.
- 86. By James Westby on 2010-01-05
-
Make the optimisation in Collection.
_get_slice apply to more cases. Collection.
_get_slice had an optimisation to fetch smaller pages if it
thought that a full page was unneeded. However, it only applied this on
the second and subsequent fetch. This change makes it apply to the first
fetch as well, as it applies there equally.

Hi,
This change helps with fetching large collections. There is
on optimisation that sets the desired page size if it looks
like a full page will be unneeded, but the way it was coded
meant that the first fetch was always full.
The change here means that the optimisation is more widely applied,
but critically for me you can actually control the size of the fetches
my looping the slices. Some API calls are liable to timeout, so
chunking them smaller allows you to use them, and that's currently
not possible. With this change you can iterate slices to control
the page size.
Thanks,
James