Merge lp:~julian-edwards/gwacl/putpage into lp:gwacl
Proposed by
Julian Edwards
Status: | Merged |
---|---|
Approved by: | Julian Edwards |
Approved revision: | 118 |
Merged at revision: | 114 |
Proposed branch: | lp:~julian-edwards/gwacl/putpage |
Merge into: | lp:gwacl |
Diff against target: |
126 lines (+105/-0) 2 files modified
storage_base.go (+35/-0) storage_base_test.go (+70/-0) |
To merge this branch: | bzr merge lp:~julian-edwards/gwacl/putpage |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raphaël Badin (community) | Approve | ||
Review via email: mp+170247@code.launchpad.net |
Commit message
Add the PutPage storage API call
Description of the change
Add the PutPage storage API call.
There's nothing particularly noteworthy here, other than that a lot of the tests are taking on a familiar sheen. My next branch will be to refactor a lot of the test setup into better factory helpers, in particular we need a factory for the storage context with a fake transport. The one that was added the other day isn't helpful and also overlaps with the non-generic one already in storage_
To post a comment you must log in.
Looks good.
[0]
8 +type PutPageRequest struct { msdn.microsoft. com/en- us/library/ windowsazure/ ee691975. aspx
9 + Container string // Container name in the storage account
10 + Filename string // The blob's file name
11 + StartRange int // Must be modulo 512, or an error is returned.
12 + EndRange int // Must be (modulo 512)-1, or an error is returned.
13 + Data io.Reader // The data to upload to the page.
14 +}
15 +
16 +// Send a request to add a range of data into a page blob.
17 +// See http://
18 +func (context *StorageContext) PutPage(req *PutPageRequest) error {
As discussed this morning, I think this is a good idea to have all our API method take structures as opposed to passing parameters. But I wonder if the container should not be excluded from PutPageRequest, and the signature of the method be something like: "PutPage(container string, req *PutPageRequest)"; this way the PutPageRequest will only capture things related to that request and could potentially be reused across different containers. What do you think?
[1]
// Check the range is set.
I know one ayatollah who would say that you don't need to say "Check" but me, I'm a good lad and I'm happy there is a comment at all ;).
[2]
Maybe this is something that belongs to a follow-up branch but I'd be happy to see this working in the field and thus I'd recommend calling this from example/ storage/ run.go.
[3]
106 +func (suite *TestPutPage) TestErrorResponse(c *C) { y("<Error> <Code>Frotzed< /Code>< Message> failed to put blob</Message> </Error> "), Response: response} ext() Transport: transport} PutPage( &PutPageRequest {
107 + response := &http.Response{
108 + Status: "102 Frotzed",
109 + StatusCode: 102,
110 + Body: makeResponseBod
111 + }
112 + transport := &TestTransport{
113 + context := makeStorageCont
114 + context.client = &http.Client{
115 + err := context.
116 + Container: "container", Filename: "filename", StartRange: 0,
117 + EndRange: 512, Data: nil})
118 + c.Assert(err, NotNil)
119 + c.Check(err, ErrorMatches, ".*102.*")
120 + c.Check(err, ErrorMatches, ".*Frotzed.*")
121 + c.Check(err, ErrorMatches, ".*failed to put blob.*")
This is really a detail but I'd advocate in favor of defining variables with the error status, the error body, etc and do the checks at the end of the methods against these variables instead of duplicating things like "failed to put blob".