Move get blob to pageable #850
Conversation
|
Note, the Continuation code for all of the generated crates will need to be updated, though the update is minimal. I will do that tomorrow. |
| pub trait Continuable { | ||
| fn continuation(&self) -> Option<String>; | ||
| fn continuation(&self) -> Option<Continuation>; |
There was a problem hiding this comment.
Do any endpoints allow for multiple types of continuations? It seems like right now the Continuation header with a continuation token is the happy path and we're using panics to ensure that we don't use a Continuation::Range when we don't meant time.
What if we were to trying the following;
pub trait Continuable {
type Continuation: crate::AsHeaders;
fn continuation(&self) -> Option<Self::Continuation>;
}The make_request function then becomes impl Fn(Option<T::Continuation>) -> F + Clone + 'static + Send
This would make the system more robust. Every continuable response just needs to provide the headers it uses for specifying how it continues.
There was a problem hiding this comment.
Examples of different Continuation methods:
- BlobClient.get uses Range header
- Cosmos's list_attachments uses
Continuationheader - ContainerClient.list_blobs uses
markerURI parameter - datalake's file_systems_list uses
makerURI parameter. Note, this one also accepts next_marker from the builder, which probably shouldn't be available.
There was a problem hiding this comment.
Ok so we couldn't do type Continuation: crate::AsHeaders but we could do type Continuation: crate::AsContinuation and implement AsContinuation for all the appropriate types.
| @@ -173,6 +129,62 @@ impl Continuable for GetBlobResponse { | |||
| } | |||
| } | |||
|
|
|||
| // caclculate the first Range for use at the beginning of the Pageable. | |||
There was a problem hiding this comment.
FYI: even though these are internal APIs they should still be /// doc comments so that they show up in rust-analyzer.
This PR does two main things:
Continuationmodel to support String (as used by most of the SDKs) andRangeas used byget_blob.get_blobto not require the user to specify a chunk size, but by default will download in 1MB chunks. I think this simplifies the interface while also not shooting the user in the foot by default downloading the entire blob into memory.