Merge lp:~jtv/gwacl/batch-list-containers into lp:gwacl
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | 102 |
Merged at revision: | 96 |
Proposed branch: | lp:~jtv/gwacl/batch-list-containers |
Merge into: | lp:gwacl |
Diff against target: |
329 lines (+135/-30) 5 files modified
Makefile (+0/-2) storage_base.go (+53/-11) storage_base_test.go (+56/-10) testhelpers_http.go (+25/-4) testhelpers_misc.go (+1/-3) |
To merge this branch: | bzr merge lp:~jtv/gwacl/batch-list-containers |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raphaël Badin (community) | Approve | ||
Review via email: mp+160844@code.launchpad.net |
Commit message
Support batched results in ListContainers().
Description of the change
This is actually required for ListContainers() to function properly. I kept the existing tests, but removed a NextMarker in an existing test. That test value was inappropriate (it was an unbatched result, so should not have a NextMarker) and broke the test once I had batch support working. Plus of course I added a test for a batching call before actually implementing support.
The code I ended up with isn't as simple as I'd like. If this were python, I'd test it much more thoroughly.
You'll also note some small drive-by improvements and TODO comments. In the Makefile you'll see that gofmt with the -s (simplify) option also does the regular work of a gofmt without the -s.
In a next branch I'll be doing the exact same batching for the List Blobs call. Hopefully I'll be able to extract some shared code. These were the only two instances of batching that I found in the storage API insofar as we support it.
Jeroen
Looks good. I've got a few remarks but I'm not really familiar with that code so take them with a grain of salt.
[0]
[in ListContainers] getListContaine rsBatch( "")
54 + firstBatch, marker, err := context.
55 if err != nil {
[...]
62 + return firstBatch, err
63 + }
Is it worth returning the firstBatch if we get an error here? Unless there is a good reason why we would want to do this (and then it's worth adding to the method's documentation), it would seem more logical to me to return "nil, err" in this case…
[1]
65 + batch, nextMarker, err := context. getListContaine rsBatch( marker)
66 + if err != nil {
67 + return firstBatch, err
68 + }
(let's forget [0] for a moment here) Why returning firstBatch here? To be more coherent with the first error return clause (the one which I talk about in [0]), I'd return the accumulated batches returned so far, *including the one we just got*. But maybe (see [0]) it's even more simple to simply return "nil, err".
[2]
77 + // Since we must have arrived at the last batch, where NextMarker is empty, NextMarker = ""
78 + // it would be misleading to report the original NextMarker.
79 + firstBatch.
I don't really understand the necessity for this (but I'm not really familiar with the context). From the looks of it, you're just introducing a small difference here, compared to what one will expect to get by reading the API documentation.
[3]
I understand the necessity for the nextMarker/marker trick given the way you've done things here… but how about a simpler implementation… something like this: paste.ubuntu. com/5600649/ paste.ubuntu. com/5600647/
The method: http://
The diff: http://