Move storage blobs to pipeline architecture #843
Conversation
Changes beyond the into_future pattern updates: 1. This updates ContentDisposition, ContentEncoding, ContentLanguage, and ContentType to follow other header types. 2. This adds a `BlobClient.get_content` helper that iterates over `BlobClient.get().stream()` and writes the data into a single Vec, returning the Vec. This was an extremely common pattern in the examples and something akin to it is available in most of the other SDKs as well. TODO: * move container operations to the into_future model
|
Note, this does not move |
There was a problem hiding this comment.
Reviewed together with @yoshuawuyts 🧡
There are some small things that we think we should change, but feel free to do those in a follow up PR if you want.
| use azure_core::{ | ||
| auth::TokenCredential, | ||
| error::{Error, ErrorKind, ResultExt}, | ||
| headers::*, | ||
| ClientOptions, Context, HttpClient, Pipeline, Request, Response, | ||
| }; |
There was a problem hiding this comment.
Nit: we don't seem to have a consistent way of structuring imports. I'd like to figure out a consistent way of structuring these things and stick to that across all of the SDKs.
There was a problem hiding this comment.
Agreed, preferably using imports_granularity once it stabilizes.
| let storage_account_client = | ||
| StorageAccountClient::new_access_key(http_client, &account, &account_key); | ||
|
|
||
| let blob_service_client = storage_account_client.as_blob_service_client(); |
There was a problem hiding this comment.
In Cosmos, we would use the naming convention storage_account_client.blob_client(). This was discussed in a previous PR
There was a problem hiding this comment.
I'll do this change as a follow-up PR, as I'd like feedback on it uniquely.
No description provided.