[Storage] [WIP] Handwritten BlockBlobClient
#2505
Conversation
|
API change check APIView has identified API level changes in this PR and created following API reviews. |
| /// * `options` - Optional configuration for the client. | ||
| pub fn get_block_blob_client( | ||
| &self, | ||
| options: Option<BlockBlobClientOptions>, |
There was a problem hiding this comment.
Do we have a precedent on whether sub-clients should inherit options, or should they be explicitly set and default otherwise.
I think for Service vs. Container vs. Blob it makes sense to not be passing the options bag, but I could see the argument since these subclients are all Blob-based -- but wanted to see if we have any precedent in other languages.
There was a problem hiding this comment.
Also, will change this to block_blob_client as per subclient naming guidelines.
| @@ -65,6 +65,7 @@ async fn test_get_blob_properties(ctx: TestContext) -> Result<(), Box<dyn Error> | |||
| let data = b"hello rusty world"; | |||
|
|
|||
| blob_client | |||
| .get_block_blob_client(None)? | |||
There was a problem hiding this comment.
NOTE (applies to all lines in test code):
- I just did a simple F+R to get the tests passing locally -- there is still tons of better practice things to do here such as use a common
BlockBlobClientinstance for multiple API calls etc. The PR ahead of this introduces tons of test helper utilities but I didn't want to block on an unrelated issue.
| /// If False, the operation will fail with ResourceExistsError. | ||
| /// * `content_length` - Total length of the blob data to be uploaded. | ||
| /// * `options` - Optional configuration for the request. | ||
| pub async fn upload( |
There was a problem hiding this comment.
Leave this in base blob client.
This is WIP and does not include any recordings. Currently a proof of concept to discuss some design questions regarding sub Blob clients.
Tests will fail in CI due to lack of recordings